Shlom Marom wrote:
> 1. is it relevant also for gcc (not g++)
If you're asking if there's a problem linking C code with static libgcc
then I would guess it's probably not an issue since you cannot throw or
catch exceptions in C.
> 2. what is the reason for that?
I don't know the specific reason for your case, but I can think of
several general reasons why static linking libgcc would be a problem.
The first is that it creates the possibility for multiple instances of
the unwinder in the final process, each unaware of the other. For
example, suppose you had a main program and a library, each linked
statically to libgcc. Each would register their unwind information
(either .eh_frame FDE tables for DWARF-2, or function contexts for SJLJ,
or whatever) with their own separate copy of the unwinder. If one tried
to throw to the other, the unwinder would not find any handler since it
would be unaware of the registered info from the other module, and would
probably abort/terminate with an uncaught exception. By having libgcc
be a shared object there is only ever one instance shared by all the
modules in the process.
The other potential issue is that when statically linking the link
editor only selects objects from an archive that contain symbols that
have been referenced by something in the objects it's scanned so far.
All unreferenced objects are discarded. If there were routines
necessary by the unwinder at runtime that are not directly referenced by
user code, they wouldn't be included in the link. I don't know if this
is actually a problem in reality or not, but if it is you might be able
to use -Wl,--whole-archive (or whatever the AIX linker calls it if not
using the GNU linker) to work around it.
Another reason could simply be that the initialization of the unwinder
and registration of unwind info requires hooks only available to a
shared library, such as the DT_INIT/DT_FINI dynamic tags (corresponding
to the .init and .fini sections.)
> 3. is it common to distribute a gcc llib with your product? do you
> know anyhing about the licensing issue?
To answer that question look at the code. Every file has a copyright
header. In the case of libgcc you should look at gcc/libgcc2.{c,h}, one
or more of gcc/unwind*, and probably one or more gcc/gthr*. The
specific files that get linked into libgcc depend on details of the
target.
But I'll save you the work. libgcc is licensed under GPLv2 with the
"runtime exception" clause, which is intended to allow unrestricted use
of the gcc libraries when linked with your code -- just using gcc to
build something doesn't require that thing to be GPL. You can think of
it another way: you're already distributing libgcc code with your
product (statically linked into it) so switching to shared libgcc
doesn't really change the situation. But as with all things legal,
consult a lawyer if you want real definitive answers, et cetera.
As to whether it's common to distribute libgcc, I guess that varies
widely. If you're talking about linux then it would be hard to find a
system without a shared copy of libgcc already on the system so it's
usually not necessary to distribute it. However, there can be problems
if the compiler you use contains a more recent version of libgcc than
what's on the user's system so I suppose there's always some need for
distributing libgcc if it's not possible to statically link it. In
general though distributing binary software is a whole separate
headache, spanning much more than just libgcc.
Brian
