[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
build tree references in installed .la file (was: libtool installation p
build tree references in installed .la file (was: libtool installation problem)
Wed, 23 Mar 2005 17:39:13 +0100
* Bob Friesenhahn wrote on Wed, Mar 23, 2005 at 03:57:14PM CET:
> On Wed, 23 Mar 2005, Ralf Wildenhues wrote:
> >* Ambarish Mitra wrote on Wed, Mar 23, 2005 at 07:29:00AM CET:
> >>The libstdc++.la has dependencies as:
> >> -lm -lm -lm -L/usr2/SOURCES/S8/gcc-3.3/objdir/gcc
> >>-L/usr/local/sparc-sun-solaris2.8/bin -L/usr/local/sparc-sun-solaris2.8/lib
> >> -L/usr/ccs/bin -L/usr/ccs/lib
> >>-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/../.. -lgcc_s -lgcc_s -lm
> >>-lgcc_s -lgcc_s'
> >OK. So this is a broken installation as well.
> "Broken" installations of GCC which depend on the uninstalled build
> directory are "normal". I recall submitting a GCC bug report some
> time ago regarding this issue. While it seems like a serious issue to
> me, it has persisted across many GCC releases.
Yes, it is. Potentially a security one, too, as many people build
in /tmp and then _do_ remove their build tree.
If I had time, I would look into this issue. But digging into an old
and modified Libtool is not something I start doing on a free night.
My first idea was -- to admit defeat in a way -- to add a Libtool option
which would remove any references to the directory tree under /some/path
for installed .la files. An obvious candidate for this path would be
But hey -- that doesn't work! I mean, it gives you broken .la files in
general. In a similar scenario, you'd pick up, say, /usr/lib/libgcc_s,
where you actually want to pick up
I wonder whether creating a libtool .la file for libgcc/libgcc_s (and,
if necessary, any other non-libtool-created libraries in the gcc tree)
would solve the matter, or whether it would need reconfiguring libtool
with the just-installed compiler (or even more than that).