tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Problem after compiling tiny CC


From: Clive Tovero
Subject: Re: [Tinycc-devel] Problem after compiling tiny CC
Date: Wed, 30 Jun 2021 19:42:18 +0000 (UTC)

> No, 'tcc -ar' should behave like 'ar'

This makes sense--looking at it as a link-time problem, rather than an archiving problem.  Just to be clear, "ar" is a library archiver, not a linker.  Maybe it is best not to conflate them.

In my example with Femtolisp, I added "-ltcc1" when using gcc to link to the static low level library ("libllt.a") compiled with tcc and archived with either "ar" or "tcc -ar".  The gcc linker resolved the symbols, and the tests worked.  Easy enough.  I'm sure there are other corner cases, like creating shared libraries using static ones, which are harder.

> The easiest way to achieve this is to compile and link with the same program.                                              

The easiest way for me was to first understand what I was trying to do. :) This topic might make a good FAQ item.  Thanks for your comments.   

arrivederci

-----Original Message-----
From: Michael Matz <matz.tcc@frakked.de>
To: Clive Tovero via Tinycc-devel <tinycc-devel@nongnu.org>
Sent: Wed, Jun 30, 2021 11:30 am
Subject: Re: [Tinycc-devel] Problem after compiling tiny CC

Hello,

On Sat, 26 Jun 2021, Elijah Stone wrote:

> On Sat, 26 Jun 2021, Clive Tovero via Tinycc-devel wrote:
>>  Also watch out for "ar", this will cause the problem too.
>
> Perhaps 'tcc -ar' should add libtcc.a automatically (unless you tell it not
> to)?  That way it would be possible to compile a static library with tcc and
> link a gcc app to it.

No, 'tcc -ar' should behave like 'ar' (within the implemented features).
It can't simply add random objects from random libraries to the output it
creates.  There's a proposal somewhere to extend the ar format to be able
to specify dependencies on libraries for the included objects, that would
be a possible half-solution.  It's only a half-solution because it
wouldn't specify search paths for the dependencies and hence would require
putting the support libs into a default lib path forever (i.e. it would
rules out the possibility to put that support lib in a compiler specific
path like GCC is doing for e.g. libgcc.a).

The situation is the same as when trying to use gcc to link stuff compiled
by g++, or to build with icc and link with clang, or when linking with ld
directly, or the old problem of compiling with -pthread but not also
linking with it.  If you do that you need to know how to link the
compilers runtime libs into the result.  The easiest way to achieve this
is to compile and link with the same program.

(for this specific instance of the problem with __mzerosf we could
possibly find an alternate solution, but I think we shouldn't bother as
there are other instances that can't be easily changed).


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]