Why does static-gnulib include -lgcc_eh?

[Bryan Ischo]

Hello. gcc builds libgcc_sh according to these rules in its

ifeq ($(enable_shared),yes)
libgcc-eh-objects += $(addsuffix $(objext),$(basename $(notdir

$(LIB2ADDEHSTATIC))))

libgcc-s-objects += $(addsuffix _s$(objext),$(basename $(notdir

$(LIB2ADDEHSHARED))))

iter-items := $(sort $(LIB2ADDEHSTATIC) $(LIB2ADDEHSHARED))
include $(iterator)
else
# Not shared. LIB2ADDEH are added to libgcc.a.
libgcc-objects += $(addsuffix $(objext),$(basename $(notdir

$(LIB2ADDEH))))

iter-items := $(LIB2ADDEH)
include $(iterator)
endif

Note that if enabled_shared is set to yes, then libgcc-eh is built;
otherwise, it is added to libgcc. And this confirms what I am seeing,
which is that gcc built with --disable-shared does not produce a
libgcc_eh.a (totally weird that if shared is enabled, libgcc_eh.a, which
is not a shared library, does get built).

Now glibc has this in its Makeconfig:

# The static libraries.
ifeq (yes,$(build-static))
link-libc-static = $(common-objpfx)libc.a $(static-gnulib)
$(common-objpfx)libc.a
else
ifeq (yes,$(build-shared))
# We can try to link the programs with lib*_pic.a...
link-libc-static = $(static-gnulib) $(common-objpfx)libc_pic.a
endif
endif
link-libc-bounded = $(common-objpfx)libc_b.a $(gnulib)
$(common-objpfx)libc_b.a

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

Note that static-gnulib is set to include -lgcc_eh; but doesn't this
conflict with gcc's Makefile? If gcc was built statically, then
libgcc_eh.a does not exist and glibc should only include -lgcc.

I'm thinking that maybe it's actually something that should be detected;
glibc doesn't know if gcc built libgcc_eh.a or not and probably
shouldn't be assuming that it did; I think that if gcc was built with
shared libraries then there will be a separate libgcc.a and libgcc_eh.a,
but if not, then there will only be libgcc.a. Whether or not glibc is
building shared libraries, static libraries or whatever, I don't think
it should be assuming what libraries are available from gcc since gcc
can produce different libraries under different build configurations.

Thanks,
Bryan

[Mike Frysinger]

oh magic archives, what do you contain !
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00100.html
http://sourceware.org/ml/libc-alpha/2005-02/msg00042.html
-mike

[Bryan Ischo]

Post by Mike Frysinger
oh magic archives, what do you contain !
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00100.html
http://sourceware.org/ml/libc-alpha/2005-02/msg00042.html
-mike

Hey thanks for the links. I guess I was on the right track.

Post by Mike Frysinger
Re: Crosscompiling issues with glibc-2.3.4
From: Ulrich Drepper <drepper at redhat dot com>
To: Jeremy Huddleston <eradicator at gentoo dot org>
Cc: libc-alpha at sources dot redhat dot com
Date: Sat, 12 Feb 2005 14:09:29 -0800
Subject: Re: Crosscompiling issues with glibc-2.3.4
Organization: Red Hat, Inc.
Cross-compiling is not supported.
--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â

That explains alot. Well, it explains why the GNU toolchain is so
crappy in this regard, but it doesn't explain why 'cross-compiling is
not supported'. A google search doesn't reveal any reasons for this,
but there is another instance where the mantra is repeated:

http://sourceware.org/bugzilla/show_bug.cgi?id=10545

Bryan

[Mike Frysinger]

Post by Bryan Ischo

Post by Mike Frysinger
oh magic archives, what do you contain !
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00100.html
http://sourceware.org/ml/libc-alpha/2005-02/msg00042.html

Hey thanks for the links. I guess I was on the right track.

Post by Mike Frysinger
Re: Crosscompiling issues with glibc-2.3.4
From: Ulrich Drepper <drepper at redhat dot com>
To: Jeremy Huddleston <eradicator at gentoo dot org>
Cc: libc-alpha at sources dot redhat dot com
Date: Sat, 12 Feb 2005 14:09:29 -0800
Subject: Re: Crosscompiling issues with glibc-2.3.4
Organization: Red Hat, Inc.
Cross-compiling is not supported.

That explains alot. Well, it explains why the GNU toolchain is so
crappy in this regard, but it doesn't explain why 'cross-compiling is
not supported'. A google search doesn't reveal any reasons for this,
http://sourceware.org/bugzilla/show_bug.cgi?id=10545

if you're looking for sensibleness i'm afraid you've come to the wrong place.
this is another reason i suggested you look at crosstool-ng: it picks up all
the "unsupported" patches to make cross-compiling work.
-mike

[Hector Oron]

Hello,

Post by Mike Frysinger
oh magic archives, what do you contain !
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00100.html
http://sourceware.org/ml/libc-alpha/2005-02/msg00042.html

It is 2011, lots of people cross compile, it benefits new architecture
bootstraping. It might be not supported, but would it be possible to
make life easier for developers, avoiding all the brain-damage, to be
able to easily bootstrap a cross variant?

With best regards,

[Mike Frysinger]

Post by Hector Oron

Post by Mike Frysinger
oh magic archives, what do you contain !
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00100.html
http://sourceware.org/ml/libc-alpha/2005-02/msg00042.html

It is 2011, lots of people cross compile, it benefits new architecture
bootstraping. It might be not supported, but would it be possible to
make life easier for developers, avoiding all the brain-damage, to be
able to easily bootstrap a cross variant?

people with permission to resolve the issue in the git source repo dont lurk
on this mailing list. and maybe i'm jaded, but i dont think you'll get a
different answer today.
-mike