This is the mail archive of the
mailing list for the libc-ports project.
Re: gcc vs. glibc bootstrapping of libgcc_eh.a
- From: Chris Metcalf <cmetcalf at tilera dot com>
- To: <linasvepstas at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>, GLIBC Devel <libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Wed, 9 Nov 2011 12:52:43 -0500
- Subject: Re: gcc vs. glibc bootstrapping of libgcc_eh.a
- References: <CAHrUA341B4RAvEFmx5pYOV7jqsLK_p9L9Jy45Y7eWoH15rjN9w@mail.gmail.com>
On 11/9/2011 12:28 PM, Linas Vepstas wrote:
I've run into a bootstrapping issue which I'd like to solve
"the right way", instead of continuing to hack around it.
Briefly: I can't build glibc without libgcc_eh.a, which is
provided by gcc. However, libgcc_eh.a is not built, unless
I configure gcc with --enable-shared. But doing so causes
gcc to attempt to build libgcc_s.so, which fails because it
wants to link to libc.so, which hasn't been built yet. And
so it goes....
The "obvious" fix, to me, is to change the libgcc/Makefile.in
to always build libgcc_eh.a (and install it) Would such a
patch be acceptable?
BTW, this is for the "hexagon" architecture, being cross-built.
Perhaps there's some other work-around that I missed...
(our current work-around is to build uClibc first, install
that, and then finish building gcc, then build glibc. Seems
pretty yucky to me.)
Take a look at the "gcc and glibc from scratch" section of
http://www.tilera.com/scm/source.html . I don't know if this will handle
your problem, but we do end up with libgcc_eh.a when the dust settles, and
it avoids having to build uClibc :-)
Chris Metcalf, Tilera Corp.