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.