www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd link mystery on linux

reply "John Belmonte" <john neggie.net> writes:
I'm having a problem where the link command line generated by dmd 
is picking up the globally-installed version of the phobos 
library instead of my local one.  I'm using a dmd.conf pointing 
at my local phobos build so this shouldn't be happening.  From 
output of "dmd rdmd.d -v":

   gcc rdmd.o -o rdmd -m64 -Xlinker 
-L/home/john/dev/d/phobos/generated/linux/release/64 -lphobos2 
-lpthread -lm -lrt

which looks right to me (referenced dir contains libphobos2.a).  
I know this is picking up the wrong phobos2 because the 
globally-installed version is missing some required symbols.  If 
I move the global .a out of the way my local lib is picked up and 
the link and subsequent run are fine.

More strangely, if I remove -Xlinker from that link line my local 
lib is again picked up.  From my understanding, omitting -Xlinker 
causes gcc to interpret the -L option natively.  Does anyone know 
why this would make a difference, or can anyone point out what 
I'm missing?

Also, I'm wondering if anyone else would find it useful for the 
update.sh tool to automatically generate a dmd.conf which points 
to the local druntime and phobos.
May 19 2012
parent reply Mike Wey <mike-wey example.com> writes:
On 05/20/2012 01:58 AM, John Belmonte wrote:

 I'm having a problem where the link command line generated by dmd is
 picking up the globally-installed version of the phobos library instead
 of my local one. I'm using a dmd.conf pointing at my local phobos build
 so this shouldn't be happening. From output of "dmd rdmd.d -v":

 gcc rdmd.o -o rdmd -m64 -Xlinker
 -L/home/john/dev/d/phobos/generated/linux/release/64 -lphobos2 -lpthread
 -lm -lrt

 which looks right to me (referenced dir contains libphobos2.a). I know
 this is picking up the wrong phobos2 because the globally-installed
 version is missing some required symbols. If I move the global .a out of
 the way my local lib is picked up and the link and subsequent run are fine.

 More strangely, if I remove -Xlinker from that link line my local lib is
 again picked up. From my understanding, omitting -Xlinker causes gcc to
 interpret the -L option natively. Does anyone know why this would make a
 difference, or can anyone point out what I'm missing?

 Also, I'm wondering if anyone else would find it useful for the
 update.sh tool to automatically generate a dmd.conf which points to the
 local druntime and phobos.


On my system it looks like the order of the commands passed on to ld 
differ depending on if -Xlinker is used.
gcc passes some default paths to the linker like: -L/lib/ and 
-L/usr/lib/, now commands passed on to the linker with -Xlinker are 
added after these paths, while if you don't use -Xlinker the path is 
passed before the default paths.

So if your global phobos lib is installed in /lib or /usr/lib it will be 
picked up by the linker if it searches those directories before the one 
that contains the local one. The search order for ld depends on the 
order in which they appear on the commandline.

-- 
Mike Wey
May 20 2012
parent reply "John Belmonte" <john neggie.net> writes:
On Sunday, 20 May 2012 at 13:53:21 UTC, Mike Wey wrote:

 On my system it looks like the order of the commands passed on 
 to ld differ depending on if -Xlinker is used.
 gcc passes some default paths to the linker like: -L/lib/ and 
 -L/usr/lib/, now commands passed on to the linker with -Xlinker 
 are added after these paths, while if you don't use -Xlinker 
 the path is passed before the default paths.

 So if your global phobos lib is installed in /lib or /usr/lib 
 it will be picked up by the linker if it searches those 
 directories before the one that contains the local one. The 
 search order for ld depends on the order in which they appear 
 on the commandline.


Thanks, that makes sense.

I found in dmd's link.c that special treatment is given to "-l" 
by eliding -Xlinker.  If I expand this logic to include -L it 
takes care of my issue.  I think it's the right thing given the 
interaction between gcc and the linker-- it's not unlikely that D 
libraries could appear in the default gcc library path and we 
want paths supplied explicitly to dmd to take precedence.  I'll 
submit a patch.

If I can get that accepted I'll try to follow up and have 
update.sh make a coherent dmd.conf.
May 20 2012
parent "John Belmonte" <john neggie.net> writes:
Tracking at http://d.puremagic.com/issues/show_bug.cgi?id=8127
May 21 2012