Re: making progress with building SH3 toolchain

[Jim Tison <jtison at ntplx dot net>]

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