[libvirt] PATCH: configure.in should use 'ld' from $PATH for checking version-script syntax, not hardcode /usr/bin/ld
Hi, I had a few minor patches which I had sent by using Bugzilla. I believe I should have sent them to this list instead... Here's the first (reference 531496 https://bugzilla.redhat.com/show_bug.cgi?id=531496) configure.in should use 'ld' from $PATH for checking version-script syntax, not hard-coded in /usr/bin/ld -Steve --- libvirt/configure.in 2009-11-08 20:57:08.194911693 -0800 +++ libvirt-ld/configure.in 2009-11-08 22:12:57.524840188 -0800 @@ -66,7 +66,7 @@ AM_PROG_CC_C_O VERSION_SCRIPT_FLAGS=-Wl,--version-script= -`/usr/bin/ld --help 2>&1 | grep -- --version-script >/dev/null` || \ +`ld --help 2>&1 | grep -- --version-script >/dev/null` || \ VERSION_SCRIPT_FLAGS="-Wl,-M -Wl," AC_SUBST(VERSION_SCRIPT_FLAGS)
On Sun, Nov 15, 2009 at 06:42:34PM -0800, Steve Yarmie wrote:
Hi, I had a few minor patches which I had sent by using Bugzilla. I believe I should have sent them to this list instead... Here's the first (reference 531496 https://bugzilla.redhat.com/show_bug.cgi?id=531496)
configure.in should use 'ld' from $PATH for checking version-script syntax, not hard-coded in /usr/bin/ld
-Steve
--- libvirt/configure.in 2009-11-08 20:57:08.194911693 -0800 +++ libvirt-ld/configure.in 2009-11-08 22:12:57.524840188 -0800 @@ -66,7 +66,7 @@ AM_PROG_CC_C_O
VERSION_SCRIPT_FLAGS=-Wl,--version-script= -`/usr/bin/ld --help 2>&1 | grep -- --version-script >/dev/null` || \ +`ld --help 2>&1 | grep -- --version-script >/dev/null` || \ VERSION_SCRIPT_FLAGS="-Wl,-M -Wl," AC_SUBST(VERSION_SCRIPT_FLAGS)
I'm not so sure about this honnestly The problem is that you don't know which linker gcc (or whatever CC is being used) will call. That can be hardcoded inside the gcc spec file for example if using a cross compiler. I have hit the issue with libxml2 in different ways because I reused that code in configure but I still don't know how to really address that properly. Using ld from $PATH might be a bit better in some case but it's really not garanteed to work in all cases, taht's painful. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Nov 16, 2009 at 02:31:39PM +0100, Daniel Veillard wrote:
On Sun, Nov 15, 2009 at 06:42:34PM -0800, Steve Yarmie wrote:
Hi, I had a few minor patches which I had sent by using Bugzilla. I believe I should have sent them to this list instead... Here's the first (reference 531496 https://bugzilla.redhat.com/show_bug.cgi?id=531496)
configure.in should use 'ld' from $PATH for checking version-script syntax, not hard-coded in /usr/bin/ld
-Steve
--- libvirt/configure.in 2009-11-08 20:57:08.194911693 -0800 +++ libvirt-ld/configure.in 2009-11-08 22:12:57.524840188 -0800 @@ -66,7 +66,7 @@ AM_PROG_CC_C_O
VERSION_SCRIPT_FLAGS=-Wl,--version-script= -`/usr/bin/ld --help 2>&1 | grep -- --version-script >/dev/null` || \ +`ld --help 2>&1 | grep -- --version-script >/dev/null` || \ VERSION_SCRIPT_FLAGS="-Wl,-M -Wl," AC_SUBST(VERSION_SCRIPT_FLAGS)
I'm not so sure about this honnestly The problem is that you don't know which linker gcc (or whatever CC is being used) will call. That can be hardcoded inside the gcc spec file for example if using a cross compiler. I have hit the issue with libxml2 in different ways because I reused that code in configure but I still don't know how to really address that properly.
Using ld from $PATH might be a bit better in some case but it's really not garanteed to work in all cases, taht's painful.
I think this is incrementally better, because it means that if someone does PATH=/opt/other/gcc/install:$PATH ./configure, then the ld check will probably work correctly, whereas current behaviour is guarenteed wrong. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Nov 16, 2009 at 01:38:12PM +0000, Daniel P. Berrange wrote:
On Mon, Nov 16, 2009 at 02:31:39PM +0100, Daniel Veillard wrote:
On Sun, Nov 15, 2009 at 06:42:34PM -0800, Steve Yarmie wrote:
Hi, I had a few minor patches which I had sent by using Bugzilla. I believe I should have sent them to this list instead... Here's the first (reference 531496 https://bugzilla.redhat.com/show_bug.cgi?id=531496)
configure.in should use 'ld' from $PATH for checking version-script syntax, not hard-coded in /usr/bin/ld
-Steve
--- libvirt/configure.in 2009-11-08 20:57:08.194911693 -0800 +++ libvirt-ld/configure.in 2009-11-08 22:12:57.524840188 -0800 @@ -66,7 +66,7 @@ AM_PROG_CC_C_O
VERSION_SCRIPT_FLAGS=-Wl,--version-script= -`/usr/bin/ld --help 2>&1 | grep -- --version-script >/dev/null` || \ +`ld --help 2>&1 | grep -- --version-script >/dev/null` || \ VERSION_SCRIPT_FLAGS="-Wl,-M -Wl," AC_SUBST(VERSION_SCRIPT_FLAGS)
I'm not so sure about this honnestly The problem is that you don't know which linker gcc (or whatever CC is being used) will call. That can be hardcoded inside the gcc spec file for example if using a cross compiler. I have hit the issue with libxml2 in different ways because I reused that code in configure but I still don't know how to really address that properly.
Using ld from $PATH might be a bit better in some case but it's really not garanteed to work in all cases, taht's painful.
I think this is incrementally better, because it means that if someone does PATH=/opt/other/gcc/install:$PATH ./configure, then the ld check will probably work correctly, whereas current behaviour is guarenteed wrong.
The only thing I could gather is using -Wl,-debug option of gcc on a compile + link simple test and then parse stderr to find 'ld ' But that's still completely gcc specific, so ACK for current patch, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 11/16/2009 03:01 PM, Daniel Veillard wrote:
The only thing I could gather is using -Wl,-debug option of gcc on a compile + link simple test and then parse stderr to find 'ld ' But that's still completely gcc specific, so ACK for current patch,
The right one is to use "`gcc --print-prog-name=ld`". Paolo
On Mon, Nov 16, 2009 at 05:15:04PM +0100, Paolo Bonzini wrote:
On 11/16/2009 03:01 PM, Daniel Veillard wrote:
The only thing I could gather is using -Wl,-debug option of gcc on a compile + link simple test and then parse stderr to find 'ld ' But that's still completely gcc specific, so ACK for current patch,
The right one is to use "`gcc --print-prog-name=ld`".
That assumes the person is using GCC, which is not a pre-requisite for libvirt. eg Solaris builds use the Solaris compiler suite Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 11/16/2009 05:19 PM, Daniel P. Berrange wrote:
That assumes the person is using GCC, which is not a pre-requisite for libvirt. eg Solaris builds use the Solaris compiler suite
In that case you can just punt and use ld. The full one would be like if test "x${LD+set}" = xset; then : elif test "x$GCC" = xyes; then LD=`$CC --print-prog-name=ld` else LD=ld fi For Solaris, using /usr/bin/ld is probably wrong more often than for Linux, since the Solaris suite would use /usr/ccs/bin/ld as far as I remember. Paolo
On Mon, Nov 16, 2009 at 05:15:04PM +0100, Paolo Bonzini wrote:
On 11/16/2009 03:01 PM, Daniel Veillard wrote:
The only thing I could gather is using -Wl,-debug option of gcc on a compile + link simple test and then parse stderr to find 'ld ' But that's still completely gcc specific, so ACK for current patch,
The right one is to use "`gcc --print-prog-name=ld`".
That gives the program name but not the path used: paphio:~/libvirt -> gcc -Wl,-debug -o tst ../tst.c 2> res paphio:~/libvirt -> grep "ld " res /usr/bin/ld --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o tst [...] /usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../lib64/crtn.o paphio:~/libvirt -> gcc --print-prog-name=ld ld paphio:~/libvirt -> so that won't differentiate ld in $PATH from /usr/bin/ld which is the actual command launched by gcc (or rather collect2) ... so unfortunately that's still gcc only and even then incomplete :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 11/16/2009 11:42 PM, Daniel Veillard wrote:
that won't differentiate ld in $PATH from /usr/bin/ld which is the actual command launched by gcc (or rather collect2) ... so unfortunately that's still gcc only and even then incomplete:-)
If --print-prog-name gives only "ld" that means collect2 will walk the $PATH. But if gcc was configured with --with-ld=something, or if a -B option is included in $CC, then --print-prog-name will print a full path. Example (PATH includes ~/bin): $ cat ~/bin/ld #! /bin/sh echo hello from "$0" > /dev/tty exec /usr/bin/ld "$@" $ gcc --print-prog-name=ld ld $ gcc f.c hello from /home/pbonzini/bin/ld $ gcc -B$HOME/bin --print-prog-name=ld /home/pbonzini/bin/ld $ gcc -B$HOME/bin f.c hello from /home/pbonzini/bin/ld $ gcc -B$HOME/./bin --print-prog-name=ld /home/pbonzini/./bin/ld $ gcc -B$HOME/./bin f.c hello from /home/pbonzini/./bin/ld HTH, Paolo
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Paolo Bonzini -
Steve Yarmie