This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Support for automatic linking via pragma


2011/3/4 H.J. Lu <hjl.tools@gmail.com>:
> 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:
>>>> On Mon, Feb 28, 2011 at 7:17 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I've submitted a feature request for automatic linking via pragma:
>>>>> http://sourceware.org/bugzilla/show_bug.cgi?id=12485
>>>>> What do others think about the idea?
>>>>
>>>> Somebody?
>>>>
>>>> Let me quote the request:
>>>> 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?
>
>> 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.
>
> --
> H.J.
>

Hello,

my 1 cent for this feature. I did some research for this feature a
while ago. Actual it is still on my todo-list for some time, but the
details of it scared me to do it actually. The additional
link-information is (for PE-COFF) in directive-section (like
additional aliasing, export-information, entry, and co). For ELF the
.comment section should be the equivalent, isn't it?

I didn't found time to work on that in more detail for PE-COFF and
indeed is for it the dependency-tree for objects/libraries the
challenging part.
As for doing this on each used object base, means we have on link-time
a changing import dependency tree, as each object actual used could
generate new one. This easily can lead to cycles and is IMHO too
costy.
So my research had shown that it would be more efficent (and not that
complex), to pre-scan those directives before the actual link-phase
and build up the object/library link dependency-tree once.
The gcc pragma implementation would be straight-forward and obvious.

Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]