Ashwani Bhat wrote:
And using '--enable-version-specific-runtime-libs' did not help
either.... :(
Yes, I should have looked at the docs, there was no mentioning about
'libiberty' being "version-specific" :-( Only about 'libstdc++-v3' etc.
So one workaround could be to install "manually" what one
needs, using the following rules for the stuff :
Command: Installs the produced
stuff from the:
--------------------------------------------------------------------------------------------------
make install-gcc 'gcc'
make install-target-libstdc++-v3 '$target/libstdc++-v3'
make install-target-libssp '$target/libssp'
.....
Depending on the "--enable-languages=" etc., different stuff will appear
into the '$build/$target' directory. But using the 'make
install-target-<stuff>'
template these could be installed separately... Or when one knows 'which'
"rule" in the 'Makefile' does the install, the Makefile itself could be
fixed and
after that the original 'Makefile.in'... When there is something wrong
with the
'install-target-libiberty', trying to fix it could be tried. A quick
investigation
told the following in the 'libiberty/configure' being the reason :
libdir='${exec_prefix}/lib'
This was then used in the produced 'Makefile' for putting the
'libiberty.a's
always into the 'lib'.... But how those 'libstdc++-v3' etc. did it
'right' wasn't
investigated... Anyhow this is a bug and someone who is more familiar with
the mechanism could maybe easily fix the 'libiberty' install lapsus...
But until this happens, just producing a script for a "installing the
parts one
by one" and "installing the 'libiberty.a's by straight copying".
Copying the
'$target/libiberty/libiberty.a' into the '/usr/lib64' and the
'$target/32/libiberty/libiberty.a' into the '/usr/lib' in your case.
And for the
rest using those 'make install-target-lib<name>' if they work "right"...
Generally the more people are reporting that the 'make install' doesn't
work
as one would expect it doing, the more probable it will be that the
"features"
in it will be fixed! I myself haven't used it for years because it
simply doesn't
do "what I expect" the installed GCC to be!
For instance putting the 'libiberty', 'libssp', 'libstdc++-v3' etc.
libs into the
'$prefix/$target/lib' as the "default" in a cross GCC is really something
uncomprehensible! They definitely are GCC-version-dependent and therefore
the default install place for them should have been the version-specific
'$prefix/lib/gcc-lib/$target/$gcc-version' (something else after gcc-3.4) !
The '--enable-version-specific-runtime-libs' isn't anything sane with
any cross
GCC because all the libraries for the $target are "linktime-libs", so
something
like "--enable-version-specific-linktime-libs" should be the option for
the "rare"?
persons who have more than one GCC for a $target, native or cross, at a
time!
My thought is that this cannot be that rare so this kind of "option"
should be the
default!
If talking about native installs, it shouldn't be hard to use symlinks
for the
'/usr/lib/libstdc++.so.<version>'s, pointing to just the GCC-versions from
which these libs came from. For instance the original 'libstdc++.so.5'
in my
system :
kai@Dell:/usr/lib> l libstdc++.so.5*
lrwxrwxrwx 1 root root 18 2006-01-19 20:04 libstdc++.so.5 ->
libstdc++.so.5.0.7*
-rwxr-xr-x 1 root root 974530 2004-10-02 01:56 libstdc++.so.5.0.7*
came from the original :
kai@Dell:/usr/lib> gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.4 (pre 3.3.5 20040809)
But if I would think to try whether the "plain vanilla" newer FSF
'gcc-3.3.6' could be
better than this "original", the '/usr/lib/libstdc++.so.5.0.7' most
probably would be overwritten
by the "experimental" gcc-3.3.6 one! If I were a newbie, could I expect
this really happening?
Should the existing "runtime" libraries be overwritten by the libraries
taken from the
experimental GCCs people maybe build and install without knowing what it
means?
I don't produce "native GCC"s, only "cross GCC"s, even for the native
$target, so I don't
need to care whether the "runtime libraries" would be overwritten... If
I would like to try
some substitute for instance for the original '/usr/lib/libstdc++.so.5',
like the :
kai@Dell:/usr/local/lib/gcc-lib/i586-suse-linux9.2/3.3.6> l
libstdc++.so.5.0.7
-rwxr-xr-x 1 root root 921834 2006-01-25 17:42 libstdc++.so.5.0.7*
just replacing the symlink would be easy... (It is smaller, but does it
really works just
as well as the original as the runtime library for the C++ apps now
using it?)
But as long as people don't report any things like these as "bugs" but
are happy with
what they have got, these things remain unfixed :-( Once again I
publicly nag about
these but probably vain....
