Re: adapting for use with TCC

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Dec 29, 2005 at 02:46:14PM CET:
> * Edward Chernenko wrote on Wed, Dec 28, 2005 at 12:34:06PM CET:
> > Hi, my system is LFS/Linux, C compiler TCC 0.9.23 and
> > I'm using
> > > GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

> All in all, I wonder whether it's better to wait for TCC to improve or
> to try to bend libtool to accomodate for TCC limitations.

Argh.  This compiler has more issues.

| $ echo 'int not_main(void) { return 0; }' > a.c
| $ tcc -c a.c
| $ tcc -o a a.o
| tcc: undefined symbol 'main'
| $ echo $?
| 0
| $ ls -l a
| ls: a: No such file or directory

Why in the world does it not reflect the failure in the return value?
This is a severe error.  I believe this is even mandated by ISO C
(and it is definitely mandated by SUS).  (causes failure of fail.at,
demo-noinst-link.test)

Also, it is claimed that `-g' gets rid of all the core dumps and helps
to output sensible error messages -- can't really see that; a testsuite
run generates several of them (mdemo, mdemo2, depdemo) and several weird
symbol lookup failures (several demo-exec instances; it seems tcc has
trouble generating a decent shared library from several objects) with
shared libraries.

For example, after demo-{conf,make}.test, the generated library works with:
$ tcc -shared .libs/foo.o .libs/hello.o -lm -lc -o .libs/libhello.so.2.1.12

but fails miserably with:
$ tcc -shared .libs/hello.o .libs/foo.o -lm -lc -o .libs/libhello.so.2.1.12
$ ./hell
/tmp/build-tcc/tests/demo/.libs/lt-hell: symbol lookup error: 
/tmp/build-tcc/tests/demo/.libs/lt-hell: undefined symbol: foo

I stopped debugging after this -- probable cause of many test failures.


We need `with_gnu_ld=no' for tcc, as it does the linking itself (and
understands hardly any GNU ld stuff).  We need to do some refactoring
first to allow to separate all of this cleanly, and then move the tcc-
specific parts in _LT_LINKER_SHLIBS down to the non-gnu-ld part --
something which I'm inclined to start post-2.0 at the earliest.

Probably the safest bet until then would be to set
  ld_shlibs=no
to disable shared library creation completely.

Cheers,
Ralf