Patchwork gcc-4.7: Add fix for libtool rpath problems

login
register
mail settings
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

Richard Purdie - Aug. 24, 2012, 2:12 p.m.
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>
---
Khem Raj - Aug. 24, 2012, 2:57 p.m.
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
Richard Purdie - Aug. 24, 2012, 3:29 p.m.
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
Andy Ross - Aug. 24, 2012, 3:53 p.m.
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
Richard Purdie - Aug. 24, 2012, 4:19 p.m.
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
Andy Ross - Aug. 24, 2012, 4:29 p.m.
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
Khem Raj - Aug. 24, 2012, 4:37 p.m.
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...
Khem Raj - Aug. 24, 2012, 4:38 p.m.
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