tinycc-devel
[Top][All Lists]
Advanced

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

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


From: Michael Matz
Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
Date: Tue, 23 Jun 2020 20:06:29 +0200 (CEST)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)

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.

reply via email to

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