This stackoverflow question raises an interesting issue with linking order and 
dmd:

http://stackoverflow.com/questions/10095150/std-net-curl-linker-errors-in-linux

I don't know if it's this way on Linux machines in general, but the OP had to 
link his program manually to be able to use std.curl. dmd appears to put the -
L argument before any of its own linker arguments, and in this case, the 
linking argument for curl needs to go on the end.

So, my question is whether dmd should be changed to put any -L arguments 
passed to it after the arguments that it passes to the linker itself. I'm far 
from an expert on this and am quite surprised that the order of arguments to 
the linker matters, but since it does, it seems to me that we should find the 
optimal order for dmd to use if we can, since it's not terribly user friendly 
to force people to call gcc or ld directly rather than using dmd to link just 
because they want to pass an argument to the linker. That's what the -L flag is 
supposed to be for.

- Jonathan M Davis

On 2012-04-11 03:46, Jonathan M Davis wrote:
> This stackoverflow question raises an interesting issue with linking order and
> dmd:
>
> http://stackoverflow.com/questions/10095150/std-net-curl-linker-errors-in-linux
>
> I don't know if it's this way on Linux machines in general, but the OP had to
> link his program manually to be able to use std.curl. dmd appears to put the -
> L argument before any of its own linker arguments, and in this case, the
> linking argument for curl needs to go on the end.
>
> So, my question is whether dmd should be changed to put any -L arguments
> passed to it after the arguments that it passes to the linker itself. I'm far
> from an expert on this and am quite surprised that the order of arguments to
> the linker matters, but since it does, it seems to me that we should find the
> optimal order for dmd to use if we can, since it's not terribly user friendly
> to force people to call gcc or ld directly rather than using dmd to link just
> because they want to pass an argument to the linker. That's what the -L flag is
> supposed to be for.
>
> - Jonathan M Davis

Could it happen that the linker arguments need to be placed first 
sometimes ?

-- 
/Jacob Carlborg

On Wednesday, April 11, 2012 10:25:37 Jacob Carlborg wrote:
> On 2012-04-11 03:46, Jonathan M Davis wrote:
> > This stackoverflow question raises an interesting issue with linking order
> > and dmd:
> > 
> > http://stackoverflow.com/questions/10095150/std-net-curl-linker-errors-in-
> > linux
> > 
> > I don't know if it's this way on Linux machines in general, but the OP had
> > to link his program manually to be able to use std.curl. dmd appears to
> > put the - L argument before any of its own linker arguments, and in this
> > case, the linking argument for curl needs to go on the end.
> > 
> > So, my question is whether dmd should be changed to put any -L arguments
> > passed to it after the arguments that it passes to the linker itself. I'm
> > far from an expert on this and am quite surprised that the order of
> > arguments to the linker matters, but since it does, it seems to me that
> > we should find the optimal order for dmd to use if we can, since it's not
> > terribly user friendly to force people to call gcc or ld directly rather
> > than using dmd to link just because they want to pass an argument to the
> > linker. That's what the -L flag is supposed to be for.
> > 
> > - Jonathan M Davis
> 
> Could it happen that the linker arguments need to be placed first
> sometimes ?

I have no idea. If they always need to be in a particular order, then we can 
just make dmd put the user provide ones in the correct spot, but if it varies 
depending on the flags, then either dmd is going to have to know which flags go 
in which order (assuming that it can), or there's no way to solve the problem 
without introducing new flags to dmd to give you more control over linking 
order or just using the linker directly.

Unfortunately, I have no idea why the linking order even matters in the first 
place, so I can't really say what we need to do here. Hopefully, someone else 
around here _does_ know. But the issue does seem to need to be brought up.

- Jonathan M Davis

On 2012-04-11 10:37, Jonathan M Davis wrote:

> I have no idea. If they always need to be in a particular order, then we can
> just make dmd put the user provide ones in the correct spot, but if it varies
> depending on the flags, then either dmd is going to have to know which flags go
> in which order (assuming that it can), or there's no way to solve the problem
> without introducing new flags to dmd to give you more control over linking
> order or just using the linker directly.
>
> Unfortunately, I have no idea why the linking order even matters in the first
> place, so I can't really say what we need to do here. Hopefully, someone else
> around here _does_ know. But the issue does seem to need to be brought up.

I also finds it strange that linking order should matter.

-- 
/Jacob Carlborg

On Wed, 11 Apr 2012 04:47:19 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2012-04-11 10:37, Jonathan M Davis wrote:
>
>> I have no idea. If they always need to be in a particular order, then  
>> we can
>> just make dmd put the user provide ones in the correct spot, but if it  
>> varies
>> depending on the flags, then either dmd is going to have to know which  
>> flags go
>> in which order (assuming that it can), or there's no way to solve the  
>> problem
>> without introducing new flags to dmd to give you more control over  
>> linking
>> order or just using the linker directly.
>>
>> Unfortunately, I have no idea why the linking order even matters in the  
>> first
>> place, so I can't really say what we need to do here. Hopefully,  
>> someone else
>> around here _does_ know. But the issue does seem to need to be brought  
>> up.
>
> I also finds it strange that linking order should matter.

It was a recent change in ld, it happened to me when I upgraded to ubutu  
11.10.

See this bug:

http://d.puremagic.com/issues/show_bug.cgi?id=6822

I remember this behavior from old systems I used to work on (really old,  
like SunOS 4).

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

My suggestion is to allow specifying in the dmd.conf file the specific  
location of phobos/druntime in the link order, then leave the -L options  
at the front.

-Steve

> Unfortunately, I have no idea why the linking order even matters in the  
> first
> place, so I can't really say what we need to do here. Hopefully, someone  
> else
> around here _does_ know. But the issue does seem to need to be brought  
> up.
>
The linker will only use succeeding archives to resolve undefined symbols,
i.e. phobos2 needs to precede curl. It seems to work when linking against
shared libraries though.

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.

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 :)

-- 
/Jacob Carlborg

"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.)

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