* gcc vs. glibc bootstrapping of libgcc_eh.a
@ 2011-11-09 17:29 Linas Vepstas
2011-11-09 17:53 ` Chris Metcalf
2011-11-10 2:50 ` Mike Frysinger
0 siblings, 2 replies; 6+ messages in thread
From: Linas Vepstas @ 2011-11-09 17:29 UTC (permalink / raw)
To: gcc, GLIBC Devel, libc-ports
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.)
--linas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gcc vs. glibc bootstrapping of libgcc_eh.a
2011-11-09 17:29 gcc vs. glibc bootstrapping of libgcc_eh.a Linas Vepstas
@ 2011-11-09 17:53 ` Chris Metcalf
2011-11-10 2:50 ` Mike Frysinger
1 sibling, 0 replies; 6+ messages in thread
From: Chris Metcalf @ 2011-11-09 17:53 UTC (permalink / raw)
To: linasvepstas; +Cc: gcc, GLIBC Devel, libc-ports
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.
http://www.tilera.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gcc vs. glibc bootstrapping of libgcc_eh.a
2011-11-09 17:29 gcc vs. glibc bootstrapping of libgcc_eh.a Linas Vepstas
2011-11-09 17:53 ` Chris Metcalf
@ 2011-11-10 2:50 ` Mike Frysinger
2011-11-11 21:27 ` Linas Vepstas
1 sibling, 1 reply; 6+ messages in thread
From: Mike Frysinger @ 2011-11-10 2:50 UTC (permalink / raw)
To: libc-ports, linasvepstas; +Cc: gcc, GLIBC Devel
[-- Attachment #1: Type: Text/Plain, Size: 88 bytes --]
comes up every few years
http://sourceware.org/ml/libc-help/2011-08/msg00073.html
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gcc vs. glibc bootstrapping of libgcc_eh.a
2011-11-10 2:50 ` Mike Frysinger
@ 2011-11-11 21:27 ` Linas Vepstas
2011-11-11 21:43 ` Ian Lance Taylor
2011-11-11 22:23 ` Mike Frysinger
0 siblings, 2 replies; 6+ messages in thread
From: Linas Vepstas @ 2011-11-11 21:27 UTC (permalink / raw)
To: Mike Frysinger; +Cc: libc-ports, gcc, GLIBC Devel
Thanks Mike, silly me, it seems that crosstool_ng is exactly what I need!
Off-topic, but .. anyone have a clue about why my canadian-cross of
gcc is picking up its own internal limits.h, instead of glibc's
limits.h? Since gcc's limits.h doesn't have ‘SSIZE_MAX’ which
gcc/config/host-linux.c wants. I suppose I can just google the
answer, can't I?
--linas
On 9 November 2011 20:49, Mike Frysinger <vapier@gentoo.org> wrote:
> comes up every few years
> http://sourceware.org/ml/libc-help/2011-08/msg00073.html
> -mike
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gcc vs. glibc bootstrapping of libgcc_eh.a
2011-11-11 21:27 ` Linas Vepstas
@ 2011-11-11 21:43 ` Ian Lance Taylor
2011-11-11 22:23 ` Mike Frysinger
1 sibling, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 2011-11-11 21:43 UTC (permalink / raw)
To: linasvepstas; +Cc: Mike Frysinger, libc-ports, gcc, GLIBC Devel
Linas Vepstas <linasvepstas@gmail.com> writes:
> Thanks Mike, silly me, it seems that crosstool_ng is exactly what I need!
>
> Off-topic, but .. anyone have a clue about why my canadian-cross of
> gcc is picking up its own internal limits.h, instead of glibc's
> limits.h? Since gcc's limits.h doesn't have ‘SSIZE_MAX’ which
> gcc/config/host-linux.c wants. I suppose I can just google the
> answer, can't I?
To clarify, your Canadian Cross should always be using gcc's internal
limits.h, so that is not surprising. The right question is why the
internal limits.h does not have a #include_next of the glibc limits.h
(via syslimits.h). I don't know the answer in your case, but I do know
that the test for whether there is a system limits.h, and that therefore
gcc should use a #include_next, is a fragile one.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gcc vs. glibc bootstrapping of libgcc_eh.a
2011-11-11 21:27 ` Linas Vepstas
2011-11-11 21:43 ` Ian Lance Taylor
@ 2011-11-11 22:23 ` Mike Frysinger
1 sibling, 0 replies; 6+ messages in thread
From: Mike Frysinger @ 2011-11-11 22:23 UTC (permalink / raw)
To: linasvepstas; +Cc: libc-ports, gcc, GLIBC Devel
[-- Attachment #1: Type: Text/Plain, Size: 813 bytes --]
On Friday 11 November 2011 16:27:18 Linas Vepstas wrote:
> Thanks Mike, silly me, it seems that crosstool_ng is exactly what I need!
>
> Off-topic, but .. anyone have a clue about why my canadian-cross of
> gcc is picking up its own internal limits.h, instead of glibc's
> limits.h? Since gcc's limits.h doesn't have ‘SSIZE_MAX’ which
> gcc/config/host-linux.c wants. I suppose I can just google the
> answer, can't I?
gcc is supposed to provide a limits.h. but at the end of that file, it does:
#include_next <limits.h>
this way you get both the gcc and the glibc defines.
what you're asking about is semi-common, but it's been so long since i solved
that issue that i don't remember the answer off the top of my head. i do know
that crosstool-ng takes care of it for you ;).
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-11-11 22:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-09 17:29 gcc vs. glibc bootstrapping of libgcc_eh.a Linas Vepstas
2011-11-09 17:53 ` Chris Metcalf
2011-11-10 2:50 ` Mike Frysinger
2011-11-11 21:27 ` Linas Vepstas
2011-11-11 21:43 ` Ian Lance Taylor
2011-11-11 22:23 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).