Hi brian,
tx a lot for the great answer!
Shlom
On Sat, Mar 22, 2008 at 5:24 AM, Brian Dessent <brian@xxxxxxxxxxx> wrote:
>
> 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
>
