View mode: basic / threaded / horizontal-split · Log in · Help
April 11, 2012
dmd's linking order
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
April 11, 2012
Re: dmd's linking order
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
April 11, 2012
Re: dmd's linking order
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
April 11, 2012
Re: dmd's linking order
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
April 11, 2012
Re: dmd's linking order
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
April 11, 2012
Re: dmd's linking order
> 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.
April 11, 2012
Re: dmd's linking order
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.
April 11, 2012
Re: dmd's linking order
On Wed, Apr 11, 2012 at 01:37:48AM -0700, Jonathan M Davis wrote:
[...]
> 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.
[...]

This is because many linkers (including *nix ld, IIRC) resolve symbols
in the order the libraries were specified on the command-line. I don't
remember the exact reason for this, but it probably has to do with
improving the performance of the symbol resolution algorithm. It's a
legacy from the early days of linker technology.


T

-- 
VI = Visual Irritation
April 11, 2012
Re: dmd's linking order
On Wed, 11 Apr 2012 13:04:59 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx>  
wrote:

> On Wed, Apr 11, 2012 at 01:37:48AM -0700, Jonathan M Davis wrote:
> [...]
>> 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.
> [...]
>
> This is because many linkers (including *nix ld, IIRC) resolve symbols
> in the order the libraries were specified on the command-line. I don't
> remember the exact reason for this, but it probably has to do with
> improving the performance of the symbol resolution algorithm. It's a
> legacy from the early days of linker technology.

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.

I'm not sure that the reasoning was that it's "simpler", because clearly  
it's possible (and implemented!)

Look for my other post for Ubuntu's explanation why, I don't really  
understand it.

-Steve
April 11, 2012
Re: dmd's linking order
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home