> 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....@frakked.de] Sent: Tuesday, June 23, 2020 20:06 To: jull...@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. _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel