This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
You've targeted the proper file, and your initial reaction is proper. I run it (for another --target) with gnulib set to just -lgcc, as follows: ****************** start patch ***************** --- ./glibc-2.3.3/Makeconfig.orig 2005-02-24 15:08:43.000000000 -0500 +++ ./glibc-2.3.3/Makeconfig 2005-02-24 15:09:12.000000000 -0500 @@ -511,7 +511,7 @@ link-extra-libs-bounded = $(foreach lib,$(LDLIBS-$(@F:%-bp=%)),$(common-objpfx)$(lib)_b.a) ifndef gnulib -gnulib := -lgcc -lgcc_eh +gnulib := -lgcc endif ifeq ($(elf),yes) +preinit = $(addprefix $(csu-objpfx),crti.o) ******************* end patch ****************** Pls pardon the line squishing ... Evolution loves to do this to me. libgcc_eh.a isn't built in Phase 1 (see below), so wherever you find it in glibc (I haven't needed to try 2.3.4 or later yet), you need to remove the gcc/ld switch values that refer to it. I did some research on this one. There are 5 functions in libgcc_eh.a ... the unwind* and gthr-* functions, specifically. These same 5 functions are found in libgcc.a, and they're exact duplicates of each other, at least in my situation. BUT ... libgcc_eh.a isn't even built in Phase 1 ... it doesn't build until Phase 3. Hence, in Phase 2 (glibc build), the link fails because -lgcc_eh doesn't resolve to anything in the Phase 1 cross implementation. The <gnulib> setting seems to need tweaking for every other release of glibc. I haven't a clue why ... it just looks like one of those casual decision things per ChangeLog. Sometimes -lgcc_eh is there, sometimes it isn't. I'd guess it has to do with how the glibc build was tested before release. If you build glibc with a native compiler (or really, your post-Phase 3 cross), libgcc_eh.a is there and is found thru the installed gcc. Just patch it out, I guess, and you're set to go for any mix of Phase 1 or 3 gcc compilers, native or otherwise (??). I'm like Dan ... I start every new tarball release pristine and try to keep it that way. But I've seen this one too many times: you've just gotta give up and patch it. Peace, --Jim-- On Sun, 2005-04-03 at 11:02, Robert P. J. Day wrote: > with a CVS-based glibc-20050402, i'm getting a familiar "-lgcc_eh" > error whose patch history in patching Makeconfig is: > > * it's patched in glibc-2.3.3 > * it's not patched in glibc-2.3.4 > * it's patched in glibc-20040827 > > and now, it appears that it needs patching again in glibc-20050402, > but the older patch doesn't apply cleanly. here's the salient excerpt > from Makeconfig in that CVS glibc, which has a different structure > from that file in glibc-20040827: > > ... > ifndef gnulib > ifneq ($(have-cc-with-libunwind),yes) > libunwind = > else > libunwind = -lunwind > endif > ifneq ($(have-as-needed),yes) > libgcc_eh := -lgcc_eh $(libunwind) > else > libgcc_eh := -Wl,--as-needed -lgcc_s$(libgcc_s_suffix) $(libunwind) > -Wl,--no-as-needed > endif > gnulib := -lgcc $(libgcc_eh) ??? > static-gnulib := -lgcc -lgcc_eh $(libunwind) ??? > libc.so-gnulib := -lgcc > endif > ... > > > my initial reaction is to just remove the "gcc_eh" references from > the questionable lines and try again, but there's also that "gcc_eh" > reference further up as well. thoughts? > > rday ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |