Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
It's OK; I get the point.
Thanks,
Arnold
"Christian Jullien" wrote:
> Arnold, here is non-working example on macos (Catalina) with mob:
>
> --- foo.c
>
> int foo = 1;
>
>
>
> --- main.c
>
> #include
>
> extern int foo;
>
> int
>
> main() {
>
> printf("foo: %d\n", foo);
>
> }
>
>
>
> jullien@byas /tmp % tcc -o foo.o -c foo.c
>
> jullien@byas /tmp % ar cru libfoo.a foo.o
>
> jullien@byas /tmp % tcc -o foo main.c -L. -lfoo
>
> tcc: error: undefined symbol '_foo'
>
> jullien@byas /tmp % nm libfoo.a
>
>
>
> foo.o:
>
> D _foo
>
>
>
>
>
> But:
>
> jullien@byas /tmp % rm libfoo.a
>
> jullien@byas /tmp % tcc -ar cru libfoo.a foo.o
>
> jullien@byas /tmp % tcc -o foo main.c -L. -lfoo
>
> jullien@byas /tmp % ./foo
>
> foo: 1
>
> jullien@byas /tmp %
>
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of Christian Jullien
> Sent: Wednesday, June 24, 2020 16:37
> To: arn...@skeeve.com; tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and
> tcc .o are not compatible
>
>
>
> Sure that's also what I do on the different Linux that support tcc (x86,
>
> x86_64, arm, aarch64, riscv).
>
> On macos it does not work because it fails when trying to "ar *.o" as .o are
>
> not MACH-O but ELF. macOS version of ar silently drop them.
>
> To work, you have to adapt configure.ac to use "tcc -ar" instead of ar *AND*
>
> no longer call ranlib.
>
>
>
> C.
>
>
>
> -Original Message-
>
> From: arn...@skeeve.com [mailto:arn...@skeeve.com]
>
> Sent: Wednesday, June 24, 2020 16:29
>
> To: tinycc-devel@nongnu.org; jull...@eligis.com
>
> Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and
>
> tcc .o are not compatible
>
>
>
> "Christian Jullien" wrote:
>
>
>
> > I think that what annoys me the most is that standard ar and ranlib
>
> commands do not work with tcc generated .o files.
>
> > For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this
>
> must be done in every configure.ac and standard .m4 you have or use.
>
> > It means that you probably won't be able to use any open source package
>
> with "CC=tcc ./configure".
>
>
>
> I build gawk that way on Linux all the time, for years. Including the
>
> static libray of support routines. So, are you sure?
>
>
>
> Arnold
>
>
>
>
>
> ___
>
> Tinycc-devel mailing list
>
> Tinycc-devel@nongnu.org
>
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
Arnold, here is non-working example on macos (Catalina) with mob:
--- foo.c
int foo = 1;
--- main.c
#include
extern int foo;
int
main() {
printf("foo: %d\n", foo);
}
jullien@byas /tmp % tcc -o foo.o -c foo.c
jullien@byas /tmp % ar cru libfoo.a foo.o
jullien@byas /tmp % tcc -o foo main.c -L. -lfoo
tcc: error: undefined symbol '_foo'
jullien@byas /tmp % nm libfoo.a
foo.o:
D _foo
But:
jullien@byas /tmp % rm libfoo.a
jullien@byas /tmp % tcc -ar cru libfoo.a foo.o
jullien@byas /tmp % tcc -o foo main.c -L. -lfoo
jullien@byas /tmp % ./foo
foo: 1
jullien@byas /tmp %
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Wednesday, June 24, 2020 16:37
To: arn...@skeeve.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and tcc
.o are not compatible
Sure that's also what I do on the different Linux that support tcc (x86,
x86_64, arm, aarch64, riscv).
On macos it does not work because it fails when trying to "ar *.o" as .o are
not MACH-O but ELF. macOS version of ar silently drop them.
To work, you have to adapt configure.ac to use "tcc -ar" instead of ar *AND*
no longer call ranlib.
C.
-Original Message-
From: arn...@skeeve.com [mailto:arn...@skeeve.com]
Sent: Wednesday, June 24, 2020 16:29
To: tinycc-devel@nongnu.org; jull...@eligis.com
Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and
tcc .o are not compatible
"Christian Jullien" wrote:
> I think that what annoys me the most is that standard ar and ranlib
commands do not work with tcc generated .o files.
> For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this
must be done in every configure.ac and standard .m4 you have or use.
> It means that you probably won't be able to use any open source package
with "CC=tcc ./configure".
I build gawk that way on Linux all the time, for years. Including the
static libray of support routines. So, are you sure?
Arnold
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
Sure that's also what I do on the different Linux that support tcc (x86, x86_64, arm, aarch64, riscv). On macos it does not work because it fails when trying to "ar *.o" as .o are not MACH-O but ELF. macOS version of ar silently drop them. To work, you have to adapt configure.ac to use "tcc -ar" instead of ar *AND* no longer call ranlib. C. -Original Message- From: arn...@skeeve.com [mailto:arn...@skeeve.com] Sent: Wednesday, June 24, 2020 16:29 To: tinycc-devel@nongnu.org; jull...@eligis.com Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible "Christian Jullien" wrote: > I think that what annoys me the most is that standard ar and ranlib commands do not work with tcc generated .o files. > For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this must be done in every configure.ac and standard .m4 you have or use. > It means that you probably won't be able to use any open source package with "CC=tcc ./configure". I build gawk that way on Linux all the time, for years. Including the static libray of support routines. So, are you sure? Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
"Christian Jullien" wrote: > I think that what annoys me the most is that standard ar and ranlib commands > do not work with tcc generated .o files. > For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this > must be done in every configure.ac and standard .m4 you have or use. > It means that you probably won't be able to use any open source package with > "CC=tcc ./configure". I build gawk that way on Linux all the time, for years. Including the static libray of support routines. So, are you sure? Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
I think that what annoys me the most is that standard ar and ranlib commands do not work with tcc generated .o files. For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this must be done in every configure.ac and standard .m4 you have or use. It means that you probably won't be able to use any open source package with "CC=tcc ./configure". C. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Christian Jullien Sent: Tuesday, June 23, 2020 20:42 To: 'Michael Matz' Cc: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible > 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
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
> 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
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
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
Hi Michael, 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. In that case, you can't use tcc with any of them. For example, once installed, OpenLisp static libs compiled with clang go to /usr/local/lib (as with many others) ls /usr/local/lib/*.a /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 Trying to compile an application with tcc that uses a clang .a lib fails. jullien@byas src % tcc -o lisp main.c -lola64 jullien@byas src % tcc -o lisp main.c -lola64 tcc: error: undefined symbol '_olmain' tcc: error: undefined symbol '_olmemheader' You must use shared libs which are slower and introduce dependencies on executable. Reverse is true, you can't use a .a compiled with tcc with clang. A clang++ program can't statically link with tcc lib. 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. -Original Message- From: Michael Matz [mailto:matz@frakked.de] Sent: Tuesday, June 23, 2020 18:16 To: jull...@eligis.com; tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible Hello Christian, On Tue, 23 Jun 2020, Christian Jullien wrote: > As suspected, I have a proof that current version does not allow to mix > clang and tcc objects (which is of course a big issue). Well, of course, that's exactly the same as if someone tried to do similar things on Windows, the .o files from there and tcc aren't compatible either. Why do you say this is a major issue, when it isn't on Windows? Personally I think this restriction is perfectly fine, how often do you copy over .o files from somewhere else? Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
Hello Christian, On Tue, 23 Jun 2020, Christian Jullien wrote: As suspected, I have a proof that current version does not allow to mix clang and tcc objects (which is of course a big issue). Well, of course, that's exactly the same as if someone tried to do similar things on Windows, the .o files from there and tcc aren't compatible either. Why do you say this is a major issue, when it isn't on Windows? Personally I think this restriction is perfectly fine, how often do you copy over .o files from somewhere else? Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
Hi All,
As suspected, I have a proof that current version does not allow to mix
clang and tcc objects (which is of course a big issue).
The root of this issue is that a tcc .o is not a Mach-O but a ELF 64 object
file.
After successfully compiled tcc here is my test:
--- foo.c
Int foo = 1;
--- main.c
#include
extern int foo;
int
main() {
printf("foo: %d\n", foo);
}
jullien@byas tinycc % clang -O3 -c foo.c -o foo-clang.o
jullien@byas tinycc % ./tcc -c foo.c -o foo-tcc.o
jullien@byas tinycc % ls -ls foo*o
8 -rw-r--r-- 1 jullien staff 420 Jun 23 06:53 foo-clang.o
8 -rw-r--r-- 1 jullien staff 660 Jun 23 06:54 foo-tcc.o
jullien@byas tinycc % file foo-clang.o
foo-clang.o: Mach-O 64-bit object x86_64
jullien@byas tinycc % file foo-tcc.o
foo-tcc.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not
stripped
Obviously, foo-tcc.o is not seen as a Mach-O object file
Now
- when linking with clang a tcc object:
% clang main.c -o main foo-tcc.o && ./main
ld: warning: ignoring file foo-tcc.o, building for macOS-x86_64 but
attempting to link with file built for unknown-unsupported file format (
0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 )
Undefined symbols for architecture x86_64:
"_foo", referenced from:
_main in main-fc9898.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
- when linking with tcc a clang object
% tcc main.c foo-clang.o
foo-clang.o: error: foo-clang.o: unrecognized file type 0
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
