This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: powerpc-eabism, strategy for finding crt0.o
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: powerpc-eabism, strategy for finding crt0.o
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 12 Apr 2001 16:51:22 -0300
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, gcc-patches at gcc dot gnu dot org, geoffk at cygnus dot com, newlib at sources dot redhat dot com
- Organization: GCC Team, Red Hat
- References: <200104111841.f3BIfiI16248@fillmore.constant.com><org0fe8t8m.fsf@guarana.lsd.ic.unicamp.br><20010412120942.A14788@redhat.com>
On Apr 12, 2001, Richard Henderson <rth@redhat.com> wrote:
> Have a build-install directory which exactly mirrors what the real
> install directory would look like, and have everyone put what's
> needed there.
When we have shared libraries linked with shared libraries in the same
build tree, this won't work either.
On a number of systems, a library gets encoded in itself the path to
find the libraries it depends on. For example, libgcj depends on
libstdc++ (say) depends on libgcc_s: this means libstdc++ is created
such that it knows where libgcc_s is installed, and libgcj knows where
libstdc++ is installed. We just can't install them elsewhere and
expect things to work.
> I suspect that this moderately drastic change would
> actually take _less_ time than adding more locallized
> hackery, since it is certainly to be enormously more
> robust.
I don't see why it would be more robust. It's just doing with
libgloss what we already do with newlib and libstdc++-v3. I don't
want any drastic changes in the build infrastructure this close to a
release.
--
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