Re: Support for automatic linking via pragma

[Ian Lance Taylor <iant@google.com>]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Fri, Mar 4, 2011 at 8:52 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> On Fri, Mar 4, 2011 at 8:29 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>>> MSVC supports the following pragma, which can be used to automatically link a
>>>> library when a header file is included. This is used by for example Boost.
>>>>
>>>> It makes linking with the right lib a lot simpler. No more fiddling
>>>> with autoconf to detect the right lib name.
>>>>
>>>
>>> Not necessarily.  Unlike DSO, object files don't have ABI/API
>>> information. You may not link foo.o compiled with glibc 2.5/libbar
>>> 1.3 against glibc 2.13/libbar 1.9
>>
>> I don't see how that is relevant to what Olaf is talking about.
>>
>> What Olaf is saying is that he wants to be able to have a .h file
>> automatically a -l option to the link command line.
>
> Don't you need to store such information in object files?

Yes, but so what?  The meaning of the information in the object file is
"when linking, add this -l option".  That is not different from what
exists today, except that today you have to remember to add the -l
option yourself.  Today, if you have an old object file, and you add the
-l option yourself on the link line, you will have trouble.  This
proposal does not change that.  It addresses a different issue.

In the hopes of being more clear, the issue that this proposal addresses
is that if your code does a #include <glib.h>, you have to also add
-lglib on your command line.  If this proposal were implemented, the
second step would be unnecessary.  This makes writing Makefiles simpler.


>> What you are saying is that if that you have a .o file, you have to link
>> against the -l which corresponds to the .h file which was used when the
>> .o file was compiled.  That is of course a real problem, but it's a
>> problem that exists whether or not we implement the MSVC pragma.
>>
>
> There is no such problem for DSO since we can encode ABI/API
> info in DSO.

Yes, of course, but irrelevant to the issue at hand.

Ian