View mode: basic / threaded / horizontal-split · Log in · Help
April 11, 2012
Re: dmd's linking order
"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message 
news:op.wcln1rh9eav7ka@localhost.localdomain...
>
> I'm not a linker expert, but I found this page which describes the changes 
> and the reasoning:
>
> See this post: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
>

That says the order-dependent  behavior is caused by --as-needed being 
default. I'm no linker expert either, but the description of the purpose 
of --as-needed sounds...goofy and pointless (although maybe it makes sense 
for C's lack of a proper module system?).

It can be disabled, apperently, by using --no-as-needed. That page tries to 
discourage people from doing that though, but the reason it gives seems 
vague. Personally, I'd wonder whether going along with --as-needed is really 
even worth doing. (Of course, if it turns out to be easy to fix the 
ordering, then we may as well.)
April 11, 2012
Re: dmd's linking order
> Not exactly.  For example, Ubuntu 10 was perfectly happy 
> accepting libraries in any order.  Only with Ubuntu 11 did this 
> "revert" to the old way.

Actually, it looked like that. What happenned behind the doors it 
was that the linking proceeded with --as-needed and the expansion 
was on the spot.

Assume that you had libA depending on libB (but also on some 
other library that you do not use, namely libC).

if you tried to link:

gcc my_program.o -lB -lA (so, in reverse order)

this looked a bit like:

gcc my_program.o -lA -lB

BUT what really happened was that the true link command was now:

gcc my_program.o -lA -lB -lC -lB

where the "-lA -lB -lC" is the expansion of the previous "-lA".
April 11, 2012
Re: dmd's linking order
> if you tried to link:
>
> gcc my_program.o -lB -lA (so, in reverse order)

read:

gcc my_program.o -lB -lA (so, in unnatural order)

>
> this looked a bit like:
>
> gcc my_program.o -lA -lB

read:

 "it looked like the order is arbitrary"

>
> BUT what really happened was that the true link command was now:
>
> gcc my_program.o -lA -lB -lC -lB

read:

gcc my_program.o -lB -lA -lB -lC (so that the symbols of libA 
*were* resolved)

>
> where the "-lA -lB -lC" is the expansion of the previous "-lA".
April 11, 2012
Re: dmd's linking order
On 04/11/2012 09:54 PM, eles wrote:
>> if you tried to link:
>>
>> gcc my_program.o -lB -lA (so, in reverse order)
>
> read:
>
> gcc my_program.o -lB -lA (so, in unnatural order)
>
>>
>> this looked a bit like:
>>
>> gcc my_program.o -lA -lB
>
> read:
>
> "it looked like the order is arbitrary"
>
>>
>> BUT what really happened was that the true link command was now:
>>
>> gcc my_program.o -lA -lB -lC -lB
>
> read:
>
> gcc my_program.o -lB -lA -lB -lC (so that the symbols of libA *were*
> resolved)
>
>>
>> where the "-lA -lB -lC" is the expansion of the previous "-lA".
>
>
>

And to tell ld to not depend on the order in which the libs are 
specifies, you can use --start-group and --end-group.

From the ld man page:

--start-group archives --end-group
    The archives should be a list of archive files.  They may be either
    explicit file names, or -l options.

    The specified archives are searched repeatedly until no new
    undefined references are created.  Normally, an archive is searched
    only once in the order that it is specified on the command line.
    If a symbol in that archive is needed to resolve an undefined
    symbol referred to by an object in an archive that appears later on
    the command line, the linker would not be able to resolve that
    reference.  By grouping the archives, they all be searched
    repeatedly until all possible references are resolved.

    Using this option has a significant performance cost.  It is best
    to use it only when there are unavoidable circular references
    between two or more archives.

-- 
Mike Wey
April 11, 2012
Re: dmd's linking order
On 04/11/12 20:30, Jacob Carlborg wrote:
> On 2012-04-11 16:59, Sean Kelly wrote:
>> On Apr 11, 2012, at 1:25 AM, Jacob Carlborg<doob@me.com>  wrote:
>>
>>> Could it happen that the linker arguments need to be placed first sometimes ?
>>
>> If it's a user-created library then maybe. The general rule on Unix is that dependent objects need to be listed before the object they depend on.  I think the linker only does a single pass. Optlink doesn't have this problem--it's way nicer in this regard.
> 
> That would be the only case where optlink is nicer :)
> 

Umm, "-( -llib1 -llib2 -)". 
But using the correct order would be the right solution.

artur
April 12, 2012
Re: dmd's linking order
Am Wed, 11 Apr 2012 14:51:14 -0400
schrieb "Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com>:

> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message 
> news:op.wcln1rh9eav7ka@localhost.localdomain...
> >
> > I'm not a linker expert, but I found this page which describes the changes 
> > and the reasoning:
> >
> > See this post: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
> >
> 
> That says the order-dependent  behavior is caused by --as-needed being 
> default. I'm no linker expert either, but the description of the purpose 
> of --as-needed sounds...goofy and pointless (although maybe it makes sense 
> for C's lack of a proper module system?).
> 
> It can be disabled, apperently, by using --no-as-needed. That page tries to 
> discourage people from doing that though, but the reason it gives seems 
> vague. Personally, I'd wonder whether going along with --as-needed is really 
> even worth doing. (Of course, if it turns out to be easy to fix the 
> ordering, then we may as well.)

I didn't know that --as-needed causes so much trouble. We've been using it on Gentoo a while before Ubuntu made that step and I know it took a while (~a year) until all packages would compile with it.
The problem that this solved was that libraries and applications are linked to other libraries they don't actually call into. On a long stream of dependencies an application would dynamically load way more libraries than it actually uses, increasing the start time. So the linker lacked the intelligence to filter out unnecessary libraries before.
Since there are some cases, where you must link to a library anyway, you can put --no-as-needed in front of them. Look at the positive side: You can now by default link against all libraries on your system without bloating the executable! :)

-- 
Marco
April 12, 2012
Re: dmd's linking order
"Marco Leise" <Marco.Leise@gmx.de> wrote in message 
news:20120412074942.0c6bb2cd@marco-leise...
> Am Wed, 11 Apr 2012 14:51:14 -0400
> schrieb "Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com>:
>
>> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
>> news:op.wcln1rh9eav7ka@localhost.localdomain...
>> >
>> > I'm not a linker expert, but I found this page which describes the 
>> > changes
>> > and the reasoning:
>> >
>> > See this post: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
>> >
>>
>> That says the order-dependent  behavior is caused by --as-needed being
>> default. I'm no linker expert either, but the description of the purpose
>> of --as-needed sounds...goofy and pointless (although maybe it makes 
>> sense
>> for C's lack of a proper module system?).
>>
>> It can be disabled, apperently, by using --no-as-needed. That page tries 
>> to
>> discourage people from doing that though, but the reason it gives seems
>> vague. Personally, I'd wonder whether going along with --as-needed is 
>> really
>> even worth doing. (Of course, if it turns out to be easy to fix the
>> ordering, then we may as well.)
>
> I didn't know that --as-needed causes so much trouble. We've been using it 
> on Gentoo a while before Ubuntu made that step and I know it took a while 
> (~a year) until all packages would compile with it.
> The problem that this solved was that libraries and applications are 
> linked to other libraries they don't actually call into. On a long stream 
> of dependencies an application would dynamically load way more libraries 
> than it actually uses, increasing the start time. So the linker lacked the 
> intelligence to filter out unnecessary libraries before.
> Since there are some cases, where you must link to a library anyway, you 
> can put --no-as-needed in front of them. Look at the positive side: You 
> can now by default link against all libraries on your system without 
> bloating the executable! :)
>

I was under the impression ld already stripped out unused symbols anyway?
April 12, 2012
Re: dmd's linking order
> And to tell ld to not depend on the order in which the libs are 
> specifies, you can use --start-group and --end-group.
>
> From the ld man page:
>
> --start-group archives --end-group
>     The archives should be a list of archive files.  They may 
> be either
>     explicit file names, or -l options.
>
>     The specified archives are searched repeatedly until no new
>     undefined references are created.

Thanks. I knew that possibility exists, I just did not remember 
the parameters.

Thank you for documenting this here.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home