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/