On Tue, 2006-11-28 at 09:37 +0100, Fabian Groffen wrote:
<snip>
> > > Maybe we should also include the /usr/lib/CHOST/gcc/VER/ stuff in there?
> >
> > Hmm, this should be done by the gcc-wrapper.
> > IMO we don't should assume any gcc version in ld.
>
> But then we have the same problem for apps that call ld themself like
> you write below.
Maybe we could have the ld-wrapper to read rpath values from
$EPREFIX/etc/ld.so.conf ?
Then libpath of currently selected gcc gets built in, which fixes the
issue of loading different gcc-libs when gcc-version is switched :-)
Consider this binutils.ebuild snippet, which does this:
src_install() {
toolchain-binutils_src_install
if use userland_Solaris && [[ ${CHOST} == ${CTARGET} ]]; then
mv ${ED}${BINPATH}/ld{,.real} || die
cat >${ED}${BINPATH}/ld <<-EOF
#! ${EPREFIX}/bin/bash
rpath=
while read p;do
case \${p} in
/*) rpath=\${rpath}\${rpath:+:}\${p} ;;
esac
done < "${EPREFIX}/etc/ld.so.conf"
rpath=\${rpath}\${rpath:+:}"${EPREFIX}/lib:${EPREFIX}/usr/lib"
exec "${EPREFIX}${BINPATH}/ld.real" "\$@" -rpath="\${rpath}"
EOF
chmod +x ${ED}/${BINPATH}/ld || die
fi
}
But then, if sys-libs/libstdc++-v3 replaces gcc, it is required to
provide libstdc++.so.X in exact the same location.
Does it do so ?
Huh, what's this now !?!:
Have installed such ld-wrapper now and built a sample c++ prog:
$ cat xx.cc
int main(void) { return 0; }
$ g++ xx.cc
$ env -i ldd a.out
libstdc++.so.6 =>
EPREFIX//usr/lib/gcc/i386-sun-solaris2.10/4.1.1/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 =>
EPREFIX//usr/lib/gcc/i386-sun-solaris2.10/4.1.1/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
libgcc_s.so.1 => EPREFIX/lib/libgcc_s.so.1
$ env -i ldd EPREFIX//usr/lib/gcc/i386-sun-solaris2.10/4.1.1/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => EPREFIX/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
As you can see, gcc's libstdc++.so.6 is not built with that ld-wrapper
yet, resulting in having two different libgcc_s.so.1 in the runtime.
Here, just rebuilding gcc might help, but what if gcc is upgraded, built
with an older gcc ?
If done so, the previous' gcc path becomes built into the new's
libstdc++.so.6, resulting the new one depending on the old's
libgcc_s.so.1, because the old's path is in etc/ld.so.conf.
Thus, we might have to enforce this steps for upgrading gcc:
1) build the new gcc
2) activate it by using gcc-config
3) rebuild the new gcc with itself
Additionally, possibly having different versions of one sharedlib in one
process really is more bad than using them from another gcc-version as
the package was built with. Let the 'soname' ensure that they are
sufficient. This is true both for libgcc_s and libstdc++.
Or, gcc-config must not copy gcc-libs into EPREFIX/lib.
But this is unintentional according to comments in gcc-config...
And the gcc-rebuild with itself keeps being necessary.
Reflecting all that, I become more being for copying libstdc++ into
EPREFIX/lib in addition to libgcc_s, and let SONAME do its work.
/haubi/
--
[EMAIL PROTECTED] mailing list
