public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/39785] New: LD_RUN_PATH ignored
@ 2009-04-16 17:38 floris dot bruynooghe at gmail dot com
2009-04-21 17:20 ` [Bug other/39785] " pinskia at gcc dot gnu dot org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: floris dot bruynooghe at gmail dot com @ 2009-04-16 17:38 UTC (permalink / raw)
To: gcc-bugs
When compiling an application on Solaris (and AIX) gcc does add implicit -L
options to the linker to point to the location of where libgcc_s.so.1 etc. (I
imagine it does this when a prefix was used that is not in the default ld.so
search path). This results in the LD_RUN_PATH being silently ignored (LIBPATH
on AIX) which is very confusing and can take a long time to find.
It can be easily demonstrated:
flub@neptune:~/gccbug$ gcc -v
Reading specs from /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/specs
Target: sparc-sun-solaris2.8
Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --without-gnu-as --with-as=/usr/ccs/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
--enable-shared --enable-multilib --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib
--with-system-zlib --enable-languages=c,c++,f95,java,objc,ada
Thread model: posix
gcc version 4.0.2
flub@neptune:~/gccbug$ cat test.c
int main(void) {
return 0;
}
flub@neptune:~/gccbug$ LD_RUN_PATH=/opt/example.com/lib truss -af -t execve gcc
test.c
1563: execve("/opt/csw/gcc4/bin/gcc", 0xFFBFFBE4, 0xFFBFFBF0) argc = 2
1563: argv: gcc test.c
1564: execve("/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/cc1",
0x0004CE20, 0x00045958) argc = 11
1564: argv: /opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/cc1
1564: -quiet test.c -quiet -dumpbase test.c -mcpu=v7 -auxbase test
1564: -o /var/tmp//cc1uw7s1.s
1566: execve("/usr/ccs/bin/as", 0x0004CE20, 0x00045958) argc = 7
1566: argv: /usr/ccs/bin/as -Qy -s -xarch=v8 -o /var/tmp//ccqjNacX.o
1566: /var/tmp//cc1uw7s1.s
1568: execve("/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/collect2",
0x0004E248, 0x00045950) argc = 23
1568: argv:
1568: /opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/collect2
1568: -R /opt/csw/gcc4/lib -Y
1568: P,/opt/csw/gcc4/lib:/usr/ccs/lib:/usr/lib -Qy
1568: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crt1.o
1568: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crti.o
1568: /usr/ccs/lib/values-Xa.o
1568: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtbegin.o
1568: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2
1568: -L/usr/ccs/bin -L/usr/ccs/lib
1568: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../..
1568: /var/tmp//ccqjNacX.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc
1568: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtend.o
1568: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtn.o
1570: execve("/usr/ccs/bin/ld", 0x0004BE80, 0x0004A44C) argc = 23
1570: argv: /usr/ccs/bin/ld -R /opt/csw/gcc4/lib -Y
1570: P,/opt/csw/gcc4/lib:/usr/ccs/lib:/usr/lib -Qy
1570: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crt1.o
1570: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crti.o
1570: /usr/ccs/lib/values-Xa.o
1570: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtbegin.o
1570: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2
1570: -L/usr/ccs/bin -L/usr/ccs/lib
1570: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../..
1570: /var/tmp//ccqjNacX.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc
1570: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtend.o
1570: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtn.o
flub@neptune:~/gccbug$ elfdump -d a.out
Dynamic Section: .dynamic
index tag value
[0] NEEDED 0xd7 libc.so.1
[1] INIT 0x106b4
[2] FINI 0x106d0
[3] RUNPATH 0xed /opt/csw/gcc4/lib
[4] RPATH 0xed /opt/csw/gcc4/lib
[5] HASH 0x100e8
[6] STRTAB 0x102f0
[7] STRSZ 0xff
[8] SYMTAB 0x101a0
[9] SYMENT 0x10
[10] CHECKSUM 0x4a7a
[11] VERNEED 0x103f0
[12] VERNEEDNUM 0x1
[13] PLTRELSZ 0x3c
[14] PLTREL 0x7
[15] JMPREL 0x10440
[16] RELA 0x10410
[17] RELASZ 0x6c
[18] RELAENT 0xc
[19] DEBUG 0
[20] FEATURE_1 0x1 [ PARINIT ]
[21] FLAGS 0 0
[22] FLAGS_1 0 0
[23] PLTGOT 0x20710
[24] NULL 0
flub@neptune:~/gccbug$ truss -af -t execve gcc test.c -R /opt/example.com/lib
1598: execve("/opt/csw/gcc4/bin/gcc", 0xFFBFFBDC, 0xFFBFFBF0) argc = 4
1598: argv: gcc test.c -R /opt/example.com/lib
1599: execve("/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/cc1",
0x0004CEC8, 0x0004595C) argc = 11
1599: argv: /opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/cc1
1599: -quiet test.c -quiet -dumpbase test.c -mcpu=v7 -auxbase test
1599: -o /var/tmp//cciFstFw.s
1601: execve("/usr/ccs/bin/as", 0x0004CEC8, 0x0004595C) argc = 7
1601: argv: /usr/ccs/bin/as -Qy -s -xarch=v8 -o /var/tmp//ccK8MMUX.o
1601: /var/tmp//cciFstFw.s
1603: execve("/opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/collect2",
0x0004E1C8, 0x00045954) argc = 25
1603: argv:
1603: /opt/csw/gcc4/libexec/gcc/sparc-sun-solaris2.8/4.0.2/collect2
1603: -R /opt/example.com/lib -R /opt/csw/gcc4/lib -Y
1603: P,/opt/csw/gcc4/lib:/usr/ccs/lib:/usr/lib -Qy
1603: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crt1.o
1603: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crti.o
1603: /usr/ccs/lib/values-Xa.o
1603: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtbegin.o
1603: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2
1603: -L/usr/ccs/bin -L/usr/ccs/lib
1603: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../..
1603: /var/tmp//ccK8MMUX.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc
1603: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtend.o
1603: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtn.o
1605: execve("/usr/ccs/bin/ld", 0x0004BE80, 0x0004A450) argc = 25
1605: argv: /usr/ccs/bin/ld -R /opt/example.com/lib -R
1605: /opt/csw/gcc4/lib -Y
1605: P,/opt/csw/gcc4/lib:/usr/ccs/lib:/usr/lib -Qy
1605: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crt1.o
1605: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crti.o
1605: /usr/ccs/lib/values-Xa.o
1605: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtbegin.o
1605: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2
1605: -L/usr/ccs/bin -L/usr/ccs/lib
1605: -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../..
1605: /var/tmp//ccK8MMUX.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc
1605: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtend.o
1605: /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/crtn.o
flub@neptune:~/gccbug$ elfdump -d a.out
Dynamic Section: .dynamic
index tag value
[0] NEEDED 0xd7 libc.so.1
[1] INIT 0x106c8
[2] FINI 0x106e4
[3] RUNPATH 0xed
/opt/example.com/lib:/opt/csw/gcc4/lib
[4] RPATH 0xed
/opt/example.com/lib:/opt/csw/gcc4/lib
[5] HASH 0x100e8
[6] STRTAB 0x102f0
[7] STRSZ 0x114
[8] SYMTAB 0x101a0
[9] SYMENT 0x10
[10] CHECKSUM 0x53a0
[11] VERNEED 0x10404
[12] VERNEEDNUM 0x1
[13] PLTRELSZ 0x3c
[14] PLTREL 0x7
[15] JMPREL 0x10454
[16] RELA 0x10424
[17] RELASZ 0x6c
[18] RELAENT 0xc
[19] DEBUG 0
[20] FEATURE_1 0x1 [ PARINIT ]
[21] FLAGS 0 0
[22] FLAGS_1 0 0
[23] PLTGOT 0x20724
[24] NULL 0
Just like when gcc detect you explicitly pass in -R gcc itself will start using
-R to ld for /opt/csw/gcc4/lib (in this case) it should detect that no -L or -R
option is used by the user and add /opt/csw/gcc4/lib to the LD_RUN_PATH
environment variable instead of using -L and rendering LD_RUN_PATH useless.
--
Summary: LD_RUN_PATH ignored
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: floris dot bruynooghe at gmail dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39785
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug other/39785] LD_RUN_PATH ignored
2009-04-16 17:38 [Bug c/39785] New: LD_RUN_PATH ignored floris dot bruynooghe at gmail dot com
@ 2009-04-21 17:20 ` pinskia at gcc dot gnu dot org
2009-04-21 18:23 ` floris dot bruynooghe at gmail dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-04-21 17:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-21 17:20 -------
This is not a bug in GCC, this is a feature. LD_RUN_PATH/-rpath are broken
really. They cannot be used for relocating libraries.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39785
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug other/39785] LD_RUN_PATH ignored
2009-04-16 17:38 [Bug c/39785] New: LD_RUN_PATH ignored floris dot bruynooghe at gmail dot com
2009-04-21 17:20 ` [Bug other/39785] " pinskia at gcc dot gnu dot org
@ 2009-04-21 18:23 ` floris dot bruynooghe at gmail dot com
2009-04-21 18:24 ` pinskia at gcc dot gnu dot org
2009-04-21 19:22 ` floris dot bruynooghe at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: floris dot bruynooghe at gmail dot com @ 2009-04-21 18:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from floris dot bruynooghe at gmail dot com 2009-04-21 18:23 -------
Could you refer to documentation that explains what to use instead then? The
manpage for ld does not say anything about --rpath being a bad way (the default
behaviour of GNU ld of only adding RPATH and requireing --enable-new-dtags for
RUNPATH is a bit odd IMHO but that's an other issue). Also the gcc manpage
doesn't say anything bad about them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39785
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug other/39785] LD_RUN_PATH ignored
2009-04-16 17:38 [Bug c/39785] New: LD_RUN_PATH ignored floris dot bruynooghe at gmail dot com
2009-04-21 17:20 ` [Bug other/39785] " pinskia at gcc dot gnu dot org
2009-04-21 18:23 ` floris dot bruynooghe at gmail dot com
@ 2009-04-21 18:24 ` pinskia at gcc dot gnu dot org
2009-04-21 19:22 ` floris dot bruynooghe at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-04-21 18:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-21 18:24 -------
Well RPATH cannot be overridden by ld.so which is the biggest reason why it is
bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39785
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug other/39785] LD_RUN_PATH ignored
2009-04-16 17:38 [Bug c/39785] New: LD_RUN_PATH ignored floris dot bruynooghe at gmail dot com
` (2 preceding siblings ...)
2009-04-21 18:24 ` pinskia at gcc dot gnu dot org
@ 2009-04-21 19:22 ` floris dot bruynooghe at gmail dot com
3 siblings, 0 replies; 5+ messages in thread
From: floris dot bruynooghe at gmail dot com @ 2009-04-21 19:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from floris dot bruynooghe at gmail dot com 2009-04-21 19:22 -------
Sure, that's why you should always use it together with --enable-new-dtags when
using GNU ld so you get a RUNPATH (note that for Solaris ld this is not needed,
you get a RUNPATH automatically if you use -R there).
But while I can see how this could be an argument against LD_RUN_PATH when GNU
ld is used --you need an extra option to the linker in any case-- it still
seems useful on other userlands (e.g. Solaris, AIX (where the env var is
LIBPATH but other semantics and problems are the same)). Note that ironically
enough the LD_RUN_PATH environment variable will work on a GNU-userland system
and not on Solaris where it is more useful due to the automatic RUNPATH.
Or is RUNPATH bad too? That can be overwritten by ld.so when you use the
LD_LIBRARY_PATH env var no?
(Sorry if I'm abusing this bug report, feel free to refer me to a more
appropriate place to discuss these issues.
Again, if you could refer me to documentation that explains how to make an
executable that looks for shared libs in say /opt/example.com/lib without using
RUNPATH that would help me understanding why this is a non-bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39785
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-04-21 19:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-16 17:38 [Bug c/39785] New: LD_RUN_PATH ignored floris dot bruynooghe at gmail dot com
2009-04-21 17:20 ` [Bug other/39785] " pinskia at gcc dot gnu dot org
2009-04-21 18:23 ` floris dot bruynooghe at gmail dot com
2009-04-21 18:24 ` pinskia at gcc dot gnu dot org
2009-04-21 19:22 ` floris dot bruynooghe at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).