gcc-4.7: Add fix for libtool rpath problems
PATCH 1/1 gcc-4.7: Add fix for libtool rpath problems
This avoids problems with libstdc++ having bad rpaths (/usr/lib/../.lib) in its .la file. See the patch for more information.
---
meta/recipes-devtools/gcc/gcc-4.7.inc +2 -1
@@ -1,6 +1,6 @@ require gcc-common.inc -PR = "r10" +PR = "r11" # Third digit in PV should be incremented after a minor release # happens from this branch on gcc e.g. currently its 4.7.1
@@ -74,6 +74,7 @@ SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \ file://gcc-argument-list-too-long.patch \ file://fix-g++-sysroot.patch \ file://disablesdt.patch \ + file://libtool.patch \ " S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch renamed from dev/null +29 -0
@@ -0,0 +1,29 @@ +libstdc++ from gcc-runtime gets created with -rpath=/usr/lib/../lib for qemux86-64 +when running on am x86_64 build host. + +This patch stops this speading to libdir in the libstdc++.la file within libtool. +Aguably, it shouldn't be passing this into libtool in the first place but +for now this resolves the nastiest problems this causes. + +func_normal_abspath would resolve an empty path to `pwd` so we need +to filter the zero case. + +RP 2012/8/24 + +Upstream-Status: Pending + +Index: git/ltmain.sh +=================================================================== +--- git.orig/ltmain.sh 2012-08-24 11:45:58.597087961 +0000 ++++ git/ltmain.sh 2012-08-24 12:18:37.961042581 +0000 +@@ -6359,6 +6359,10 @@ + func_warning "ignoring multiple \`-rpath's for a libtool library" + + install_libdir="$1" ++ if test -n "$install_libdir"; then ++ func_normal_abspath "$install_libdir" ++ install_libdir=$func_normal_abspath_result ++ fi + + oldlibs= + if test -z "$rpath"; then
Quoted 48 lines · Richard Purdie
This avoids problems with libstdc++ having bad rpaths (
/usr/lib/../.lib) in its .la file. See the patch for more information.Signed-off-by Richard Purdie <[email protected]>---
meta/recipes-devtools/gcc/gcc-4.7.inc +0
-0@@ -1,6 +1,6 @@require gcc-common.inc
meta/recipes-devtools/gcc/gcc-4.7.inc +1
-1-PR = "r10" +PR = "r11"# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.7.1meta/recipes-devtools/gcc/gcc-4.7.inc +1
-0@@ -74,6 +74,7 @@ SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \ file://gcc-argument-list-too-long.patch \ file://fix-g++-sysroot.patch \ file://disablesdt.patch \ + file://libtool.patch \ "S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch renamed from dev/null +17
-0@@ -0,0 +1,29 @@ +libstdc++ from gcc-runtime gets created with -rpath=/usr/lib/../lib for qemux86-64 +when running on am x86_64 build host. + +This patch stops this speading to libdir in the libstdc++.la file within libtool. +Aguably, it shouldn't be passing this into libtool in the first place but +for now this resolves the nastiest problems this causes. + +func_normal_abspath would resolve an empty path to `pwd` so we need +to filter the zero case. + +RP 2012/8/24 + +Upstream-Status: Pending + +Index: git/ltmain.sh +=================================================================== +--- git.orig/ltmain.sh 2012-08-24 11:45:58.597087961 +0000
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch line 27
Quoted 10 lines
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch renamed from dev/null +10
-0++++ git/ltmain.sh 2012-08-24 12:18:37.961042581 +0000 +@@ -6359,6 +6359,10 @@ + func_warning "ignoring multiple \`-rpath's for a libtool library" + + install_libdir="$1" ++ if test -n "$install_libdir"; then ++ func_normal_abspath "$install_libdir" ++ install_libdir=$func_normal_abspath_result ++ fi +
this looks ok to me. Did we post the libtool patch upstream ?
Quoted 9 lines
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch renamed from dev/null +2
-0+ oldlibs= + if test -z "$rpath"; then_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 54 lines · Khem Raj
Quoted 52 lines · Richard Purdie
This avoids problems with libstdc++ having bad rpaths (
/usr/lib/../.lib) in its .la file. See the patch for more information.Signed-off-by Richard Purdie <[email protected]>---
meta/recipes-devtools/gcc/gcc-4.7.inc +0
-0@@ -1,6 +1,6 @@require gcc-common.inc
meta/recipes-devtools/gcc/gcc-4.7.inc +1
-1-PR = "r10" +PR = "r11"# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.7.1meta/recipes-devtools/gcc/gcc-4.7.inc +1
-0@@ -74,6 +74,7 @@ SRC_URI = "git://github.com/mirrors/gcc.git;branch=${BRANCH};protocol=git \ file://gcc-argument-list-too-long.patch \ file://fix-g++-sysroot.patch \ file://disablesdt.patch \ + file://libtool.patch \ "S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/git"
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch renamed from dev/null +21
-0@@ -0,0 +1,29 @@ +libstdc++ from gcc-runtime gets created with -rpath=/usr/lib/../lib for qemux86-64 +when running on am x86_64 build host. + +This patch stops this speading to libdir in the libstdc++.la file within libtool. +Aguably, it shouldn't be passing this into libtool in the first place but +for now this resolves the nastiest problems this causes. + +func_normal_abspath would resolve an empty path to `pwd` so we need +to filter the zero case. + +RP 2012/8/24 + +Upstream-Status: Pending + +Index: git/ltmain.sh +=================================================================== +--- git.orig/ltmain.sh 2012-08-24 11:45:58.597087961 +0000 ++++ git/ltmain.sh 2012-08-24 12:18:37.961042581 +0000 +@@ -6359,6 +6359,10 @@ + func_warning "ignoring multiple \`-rpath's for a libtool library" +
Quoted 8 lines
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch line 27
Quoted 6 lines
meta/recipes-devtools/gcc/gcc-4.7/libtool.patch renamed from dev/null +6
-0+ install_libdir="$1" ++ if test -n "$install_libdir"; then ++ func_normal_abspath "$install_libdir" ++ install_libdir=$func_normal_abspath_result ++ fi +this looks ok to me. Did we post the libtool patch upstream ?
Not yet. We could do with going and talking to them about our libtool patchset...
Right now I'm just trying to get the builds working. I shouldn't have merged that sanity test yet :/.
Cheers,
Richard
Quoted 3 lines · Richard Purdie
Right now I'm just trying to get the builds working. I shouldn't have merged that sanity test yet :/.
I think its fine after all its master. Furthermore we are discovering latent issues not introducing new ones
Quoted 2 lines · Richard Purdie
This avoids problems with libstdc++ having bad rpaths (
/usr/lib/../.lib) in its .la file. See the patch for more information.
Heh, I was just sitting down having discovered the same thing. Isn't the root cause at least partially that gcc is using a different libtool implementation than the rest of the build? I note it's also missing the normalization patches that went into the standard libtool (though that's benign here as -rpath isn't used).
Andy
Quoted 9 lines · Andy Ross
Quoted 2 lines · Richard Purdie
This avoids problems with libstdc++ having bad rpaths (
/usr/lib/../.lib) in its .la file. See the patch for more information.Heh, I was just sitting down having discovered the same thing. Isn't the root cause at least partially that gcc is using a different libtool implementation than the rest of the build? I note it's also missing the normalization patches that went into the standard libtool (though that's benign here as -rpath isn't used).
gcc is one of the few things we don't reautoconf so it doesn't pick up our libtool. We therefore end up patching libtool in it and binutils manually which can be a bit of a pain...
I'd love to have a better fix for this. I suspect its taking the path from some "gcc -print-xxxx" call which returns /usr/lib/../lib on x86_64 so we could try and normalise it at source...
Cheers,
Richard
Quoted 3 lines · Richard Purdie
I'd love to have a better fix for this. I suspect its taking the path from some "gcc -print-xxxx" call which returns/usr/lib/../lib on
x86_64so we could try and normalise it at source...
Yeah, but that sounds like whack-a-mole to me. It's just too tempting for upstream software to glue up a path name with .., it's very sane for a human being.
One of the (comparatively few) spots where I actually isolated the source of one of these is in gettext, where the configure script needs a --with-ncurses-prefix to be "/usr". So the bitbake recipe sets it to ${STAGING_LIBDIR}/.., which seems clearly correct to me. And then somewhere in the configure script that turns into a libtool library path of <ncurses_prefix>/lib (again completely correct), thus "/usr/lib/../lib". And even then it's correct and if used for a -L argument would never cause a problem.
It's libtool which has special requirements here, becuase it's trying to set rpaths based on those funny strings and has to have them normalized. So I'd argue that it's in libtool where this magic has to happen.
Before I realized you already fixed the gcc-runtime issue, I was looking at finding a place farther up the stack where this could be done. That is, sanitize all inbound paths at the spot where they're parsed at the command line. The current cases we know we need to hit are -lib and -rpath, though I'm no libtool expert and am surely missing some...
Andy
Quoted 6 lines · Andy Ross
It's libtool which has special requirements here, becuase it's trying to set rpaths based on those funny strings and has to have them normalized. So I'd argue that it's in libtool where this magic has to happen.
yes I tend to agree
Quoted 6 lines
Before I realized you already fixed the gcc-runtime issue, I was looking at finding a place farther up the stack where this could be done. That is, sanitize all inbound paths at the spot where they're parsed at the command line. The current cases we know we need to hit are -lib and -rpath, though I'm no libtool expert and am surely missing some...