[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libstdc++.la listed in dependency_libs of a static C++ library?
From: |
Benoit Sigoure |
Subject: |
Re: libstdc++.la listed in dependency_libs of a static C++ library? |
Date: |
Sun, 22 Apr 2007 18:18:09 +0200 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.0.2) |
Quoting Benoit Sigoure <address@hidden>:
Quoting Ralf Wildenhues <address@hidden>:
That's not the only (or important, FWIW) issue here, though. The
installed libstdc++.la file is broken. Reason for that include
bugs/limitations in Libtool, bugs in GCC, and possibly in the script
that has been used to build it. (AFAIK there is a related GCC bug
listed in their bugzilla, not sure if it was 5291 and no, please
don't expect me to do an analysis of your particular issue; if I had
the time to do that, I'd be working on the GCC bug.)
Yeah I understand, that's fine by me, I simply asked for some basic analysis
because I wasn't sure that the problem really came from ELDK.
Alright so I confirm this bug, and it's due to crosstool
(http://kegel.com/crosstool/).
I can hack the .la file or simply rebuild GCC arm-linux myself.
It's almost impossible to build a cross-compiler for ARM-linux. I
tried during
3 days and ran into tons of problems (Buggy binutils, I had to heavily patch
the glibc but never succeeded in compiling a working cross-glibc, etc)
That's why I ended up using crosstool which does its job pretty nicely but
produces b0rken libstdc++.la :(
In fact, the libstdc++.la file produced works fine if and only if the
resulting
cross-compiler is NOT relocated. Should this really be considered as a
bug WRT
libstdc++.la? Because the whole thing works fine unless one links something
with a libtool library that has a dependency on libstdc++.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory