Re: [Tinycc-devel] Missing symbol when compiling in -static

[RoboTux]

Le jeudi 22 avril 2010 12:56:27, grischka a écrit :
> RoboTux wrote:
> > But one concern remains: do we really want to make tinycc depends on gcc
> > ? That sounds a bit weird to force the user to install gcc even if he
> > only wants to compile with tinycc.
> 
> Well, if you want to solve _that_ problem then you'd need to talk to
> the libc devs why their /usr/lib/libc.a depends on SEH support code
> that is buried in the private gcc subdir.

It does not strictly depends on gcc, although it has obviously been thought 
with gcc in mind. It depends on low level routine for exception handling. I 
made a few search and I found is that libgcc_eh.a provides exception handling 
for all languages handled by gcc. Exception handling needs to unwind functions 
and the way it is done implied a specific stack layout. And only the compiler 
knows this stack layout so mostly all the exception handling is done in the 
glibc but the compiler has to provides a few function for low level things.

Wikipedia explains how exception handling impact the compiler and the stack:

http://en.wikipedia.org/wiki/Exception_handling#Exception_handling_implementation
> 
> > On the other hand, provide dummy functions is
> > perfectly possible and doesn't introduce regression, even if the
> > functions aren't functional. On the contrary, they improve usability of
> > the software since it would allow many programs, which don't use the 4
> > undefined symbols neither directly, nor indirectly, to be compiled
> > statically with tinycc.
> >
> > Thus, I'd like to commit dummy functions which anyone can then transform
> > in fully functional ones.
> 
> I guess to be "fully functional" this could easily mean several versions,
> such as one for each gcc version that gnu/linux systems are compiled with.
I don't think these fonction evolves with gcc version. It's more related to 
the glibc than to gcc. The glibc provides exception handling but this 
mechanism requires some compiler support. Thus, I think it's the glibc which 
defines the API. I'll take a look to other compiler to see how they handle that 
case. Maybe llvm has an implementation we could reuse because its licence 
seems LGPL compatible. The llvm website summarize the llvm licence like this:

- You can freely distribute LLVM.
- You must retain the copyright notice if you redistribute LLVM.
- Binaries derived from LLVM must reproduce the copyright notice (e.g. in an 
included readme file).
- You can't use our names to promote your LLVM derived products.
There's no warranty on LLVM at all.

Or, as I previously said, we could implement dummy function and print a 
warning when static compiling that exception handling won't be supported.
> 
> Well, maybe I just don't understand.  Can we make "tcc -static" work with
> libgcc_eh.a, say somewhat easily?
Before what I learned recently about this I would have said :

Yes I think so. The only technical problem is to find where it is stored: 
libgcc_eh.a is in /usr/lib/gcc/<arch>gcc-<version>. But that needs anyone 
which want to use tinycc must also have gcc installed. At least if we follow 
that way we should provides a way to disable tcc static compilation in the 
configure.

But now I'm really not sure it would work. If it's provided by gcc then there 
is a good chance that it's really compiler-dependant. Except if code compiled 
by tcc and gcc looks the same, I don't think we could link against libgcc_eh.a 
It seems to me the only solution is to implement in some way the function on 
the tcc side.
> 
> --- grischka
> 
> > Thomas Preud'homme
> 
Hope I'm clear and I'm not confused myself.

signature.asc
Description: This is a digitally signed message part.