[llvm-dev] RFC: ELF Autolinking

[Zachary Turner via llvm-dev]

On Thu, Mar 14, 2019 at 9:34 AM Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> This proposal seems much better than the generic .linker-options scheme
> that potentially allows arbitrary linker options to be embedded to an
> object file. The proposed scheme is basically the same mechanism as the
> "comment lib" feature implemented on Microsoft linker, which I found mildly
> useful and at least not harmful.
>
> As a use case, what I heard of was that in the game industry where many
> developers are using Visual Studio as an IDE and familiar with Windows'
> semantics of linking, people find it annoying that to build the same
> program on Unix, they had to add bunch of -lfoo to the linker command line
> while they are automatically handled on Windows. I can understand that --
> if you have to add `-lm` 99.9% of the time when #include <math.h> for
> example, that's not too odd to think why this is not processed
> automatically.
>
> But the above story was from the game industry. Just like Ben, I'd like to
> hear from other people if they really want this feature.
>
>
 Another situation where it is useful is when a 3rd party library supports
multiple different ABI-incompatible build configurations (typically
selected between via pre-processor settings).  This way, the header file
can choose the right version of the library to link against.

This comes up often when linking against python, for example, where if you
have #defined _DEBUG then you need to link against python35_d.[dll|so]
versus python35.[dll|so].

You can certainly represent this kind of logic in a build system, but it
leads to even more maintenance burden in my experience, and in general it's
nice if things "just work".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190314/2706cc84/attachment.html>