| Submitter | Richard Purdie |
|---|---|
| Date | Aug. 24, 2012, 2:12 p.m. |
| Message ID | <1345817543.14369.70.camel@ted> |
| Download | mbox | patch |
| Permalink | /patch/35299/ |
| State | Accepted |
| Commit | bd27e81f1fa49e2770da9a4a65a83e9d4c3a0dd0 |
| Headers | show |
Comments
On Aug 24, 2012, at 7:12 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > 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 <richard.purdie@linuxfoundation.org> > --- > diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc > index 36ce1be..84c230c 100644 > --- a/meta/recipes-devtools/gcc/gcc-4.7.inc > +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc > @@ -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" > diff --git a/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch b/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch > new file mode 100644 > index 0000000..9580b23 > --- a/dev/null > +++ b/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch > @@ -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 > + this looks ok to me. Did we post the libtool patch upstream ? > + oldlibs= > + if test -z "$rpath"; then > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Fri, 2012-08-24 at 07:57 -0700, Khem Raj wrote: > On Aug 24, 2012, at 7:12 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > > 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 <richard.purdie@linuxfoundation.org> > > --- > > diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc > > index 36ce1be..84c230c 100644 > > --- a/meta/recipes-devtools/gcc/gcc-4.7.inc > > +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc > > @@ -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" > > diff --git a/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch b/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch > > new file mode 100644 > > index 0000000..9580b23 > > --- a/dev/null > > +++ b/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch > > @@ -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 > > + > > 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
On 08/24/2012 07:12 AM, Richard Purdie wrote: > 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
On Fri, 2012-08-24 at 08:53 -0700, Andy Ross wrote: > On 08/24/2012 07:12 AM, Richard Purdie wrote: > > 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
On 08/24/2012 09:19 AM, Richard Purdie wrote: > 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... 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
On Fri, Aug 24, 2012 at 9:29 AM, Andy Ross <andy.ross@windriver.com> wrote: > > 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 > 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...
On Fri, Aug 24, 2012 at 8:29 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > 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
Patch
diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc b/meta/recipes-devtools/gcc/gcc-4.7.inc index 36ce1be..84c230c 100644 --- a/meta/recipes-devtools/gcc/gcc-4.7.inc +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc @@ -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" diff --git a/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch b/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch new file mode 100644 index 0000000..9580b23 --- a/dev/null +++ b/meta/recipes-devtools/gcc/gcc-4.7/libtool.patch @@ -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
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 <richard.purdie@linuxfoundation.org> ---