Add link_syms parameter to build targets

[keith-packard]

This parameter provides a place to add -Wl,--defsym=a=b and -Wl,--undefined=c parameters during linking. These should occur before any object files and must occur before any libraries so that the results will affect the link correctly.

In the ninjabackend, this is done by adding these to the ARGS parameter during linking as that is placed in the command line before any input files or libraries.

[keith-packard]

I'm currently using a hack where I add '-lgcc' to link_args as that wraps the list of static libraries, the --defsym values and then -lgcc in --start-group, --end-group; the linker then searches the static library, processes the defsym parameters and then re-searches the static library. Having a way to insert linker args before the list of static libraries avoids needing this hack, and avoids re-scanning the static libraries.

Right now, there's no support for mapping the GNU ld --defsym=new=old syntax to the OS X -alias new old syntax. Would that be required for this patch to be merged? Or would you prefer a more structured approach where we add explicit define symbol and undefine symbol link parameters so that each linker backend could map to their own syntax? These could also add the __USER_LABEL_PREFIX__ value to support BSD-style external symbols.

[eli-schwartz]

Since the feature being added seems generic enough that its effective functionality isn't actually about defsym at all, I wonder if it's worth being a bit more direct about it and calling it link_early_args or something. :)

Which link args need to come first, which link args need to come later, etc? Currently the issue is that meson essentially doesn't really define what order any custom arguments will appear in (other than, I guess, that custom args should always tend to appear after builtin args so that they will override them where relevant).

[eli-schwartz]

Since this (new) code does KwargInfo based checking we know for sure that by the time it gets to build.py it is a list of strings, and we shouldn't need to type check it again.

[keith-packard]

Since the feature being added seems generic enough that its effective functionality isn't actually about defsym at all, I wonder if it's worth being a bit more direct about it and calling it link_early_args or something. :)

Yeah, which is one reason I asked whether this should be a set of functions that control symbol definitions instead? That would make it easier to port between linkers, and would avoid this confusion.

Which link args need to come first, which link args need to come later, etc? Currently the issue is that meson essentially doesn't really define what order any custom arguments will appear in (other than, I guess, that custom args should always tend to appear after builtin args so that they will override them where relevant).

Hrm. You've got me wondering if meson shouldn't just look at link_args and pick those which should be early and which should be late automatically? At least for now, just pulling out --defsym, --undefined and --required and placing them before the input files would have worked for my use case. And those are essentially useless if provided after all of the inputs...

[eli-schwartz]

Hrm. You've got me wondering if meson shouldn't just look at link_args and pick those which should be early and which should be late automatically?

... or even just passing them all early by default? Are there any (ignoring -l which should be handled via link_with / dependencies anyway) that specifically need to be passed late...

[keith-packard]

... or even just passing them all early by default? Are there any (ignoring -l which should be handled via link_with / dependencies anyway) that specifically need to be passed late...

I hesitate to suggest that big a change -- we're likely to break something. I guess the question is whether this should be managed automatically by meson or manually by the user?