Mainline bootstrap failure (Re: libstdc++ execute tests)

Alexandre Oliva aoliva@redhat.com
Thu Apr 12 04:57:00 GMT 2001


On Apr 12, 2001, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote:

> Additionally libstdc++ installs a $prefix/lib/libstdc++.la which
> includes the libstdc++ *build* directories in dependency_libs, with
> the result that libtool aware applications like KDE2 use them for
> their -L flags during linking...

Uh oh.  This is bad.

The problem is that libtool has no way to tell which directories
specified with -L are part of ``the current build'', so it assumes any
dependencies of the library being built might be in one of those
directories after the library is installed, so the directories must be
added to the search path of libtool.

I see two ways to avoid this:

- not use any -L flags when creating libtool libraries; instead,
specify library names explicitly.  This does The Right Thing (or at
least is supposed to) if the dependence libraries are libtool
libraries (which, unfortunately, is not the case) or static
libraries.  The shared libgcc would be a problem in this case, and
more so before the -L flag is taken implicitly from the flags the
compiler driver passes down to the linker.

- create some way to tell libtool ``look, this -L flag is to be used
only when building this particular library, it's not needed for any of
its dependencies after the library is installed.''  This might be
accomplished by specifying the root of the current build tree.  So,
libstdc++-v3 would be configured such that it would pass to libtool
something like, say -L-$(top_builddir)/$(MULTILIBTOP)/.., and libtool
would compare the prefix of the canonicalized full pathname
corresponding to $(MULTILIBTOP)/.. with that of each directory passed
in -L, and remove it from dependency_libs in the installable .la file.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



More information about the Gcc-patches mailing list