[libvirt] PATCH: configure.in should use 'ld' from $PATH for checking version-script syntax, not hardcode /usr/bin/ld
8:42 p.m.
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)
7:31 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
7:38 a.m.
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 :|
8:01 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
10:15 a.m.
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
10:19 a.m.
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 :|
10:22 a.m.
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
4:42 p.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
11:12 a.m.
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
5485
days inactive
5486
days old
8 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Paolo Bonzini -
Steve Yarmie