Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible

[Christian Jullien]

> Baeh, static libs, who uses those anymore?
Come on, you known like me that there are also advantages to use static
libs. Esp. when speed matters. With OpenLisp or other high performance C++
code I write (for low latency trading), shared lib is prohibited as
performance penalty is well above 10%.
Okay, when speed really matters I confess, when code works, I don't use tcc
and switch back to gcc. :o)

> Recompile everything with tcc! :) 
Good idea, I'll start to recompile all my C++ code with tcc :)

- End of jokes

I'm already very happy with current situation which allows to build OpenLisp
with some shared libs like readline but, unless tcc is able to produce
Mach-O objects and static libs, you can't really pretend it is a dropdown
replacement of clang.
I bet sooner than later other users will also complain. But (your) time is
precious and I don't want to ask you anything. If you're now convinced and
want to give a try, I'll be glad to test and possibly help you.
As announced by Apple yesterday, next step will be Aarch support but not
this year.

Take care.

C.

-----Original Message-----
From: Michael Matz [mailto:matz.tcc@frakked.de] 
Sent: Tuesday, June 23, 2020 20:06
To: jullien@eligis.com
Cc: tinycc-devel@nongnu.org
Subject: RE: [Tinycc-devel] Major issue with current macos port. clang and
tcc .o are not compatible

Hello,

On Tue, 23 Jun 2020, Christian Jullien wrote:

> I agree that it is the same on Windows however on macOS and more 
> generally on unix systems it is not uncommon to have components shipped 
> as static libs (.a).
> 
> While I never copy .o I very often use .a installed on my system.

Baeh, static libs, who uses those anymore? :-)  Recompile everything with 
tcc! :)

More seriously: I could be convinced to write a simple Mach-O .o file 
reader, but that itself doesn't completely guarantee that all random .o 
files produced by gcc or clang could be used, and some of those would 
expose really large holes in tcc's support of some features (e.g. TLS, and 
some fancy relocations), so it's unclear how far this goes.

Instead one could also write a simple Mach-O .o file writer, that would 
then only need the features that TCC is using.  But then TCC couldn't be 
used for linking anymore, that would need the reading part again and would 
feel against the spirit of TCC (an all-in-one toolchain).  So the reader 
would be necessary again, going back to the above problems of potential 
incompleteness.

I'll see how a mach-o .o reader looks like, the .dylib "loader" is 
implementing some of the necessities, so it might turn out to not need too 
many lines of code and not look too ugly (these two are important goals to 
me personally for TCC) and be not too incomplete to be of use.

> For example, once installed, OpenLisp static libs compiled with clang go 
> to /usr/local/lib (as with many others)
> 
> /usr/local/lib/libasprintf.a           
> /usr/local/lib/libgmp.a                 /usr/local/lib/libpcre2-16.a
> 
> /usr/local/lib/libcord.a               
> /usr/local/lib/libgmpxx.a               /usr/local/lib/libpcre2-32.a
> 
> /usr/local/lib/libevent.a 
>              /usr/local/lib/libguile-3.0.a          
> /usr/local/lib/libpcre2-8.a
> 
> /usr/local/lib/libevent_core.a         
> /usr/local/lib/libhogweed.a             /usr/local/lib/libpcre2-posix.a
> 
> /usr/local/lib/libevent_extra.a        
> /usr/local/lib/libidn2.a                /usr/local/lib/libtasn1.a
> 
> /usr/local/lib/libevent_openssl.a      
> /usr/local/lib/libintl.a                /usr/local/lib/libtcc.a
> 
> /usr/local/lib/libevent_pthreads.a     
> /usr/local/lib/libltdl.a                /usr/local/lib/libtextstyle.a
> 
> /usr/local/lib/libgc.a                 
> /usr/local/lib/liblzma.a                /usr/local/lib/libunbound.a
> 
> /usr/local/lib/libgccpp.a              
> /usr/local/lib/libnettle.a              /usr/local/lib/libunistring.a
> 
> /usr/local/lib/libgdbm.a                /usr/local/lib/libola64.a
> 
> /usr/local/lib/libgettextpo.a           /usr/local/lib/libolcpa64.a

Many of those are projects written in C, so the above recompiling 
everything in TCC (half in jest!) would be somewhat feasible even :)

> Don?t think I loudly complain. I really enjoy this first version and the 
> amazing work you did.
> 
> I hope you agree with all my macos commits which try to make the port 
> even better.

Yep, they make things strictly better, thanks for those!


Ciao,
Michael.