April 11, 2012
"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
> 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
> 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
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
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
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
"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
> 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.
1 2
Next ›   Last »