Jump to page: 1 2
Thread overview
dmd's linking order
Apr 11, 2012
Jonathan M Davis
Apr 11, 2012
Jacob Carlborg
Apr 11, 2012
Jonathan M Davis
Apr 11, 2012
Jacob Carlborg
Apr 11, 2012
Nick Sabalausky
Apr 12, 2012
Marco Leise
Apr 12, 2012
Nick Sabalausky
Apr 11, 2012
Martin Nowak
Apr 11, 2012
Sean Kelly
Apr 11, 2012
Jacob Carlborg
Apr 11, 2012
Artur Skawina
Apr 11, 2012
H. S. Teoh
Apr 11, 2012
eles
Apr 11, 2012
eles
Apr 11, 2012
Mike Wey
Apr 12, 2012
eles
April 11, 2012
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
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
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
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
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
> 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
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
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
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
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