Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
You can compile but not link. Maybe you need and extra package for the linker. $ gcc -m32 foo.c /usr/local/bin/ld: skipping incompatible /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/libgcc.a when searching for -lgcc /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc.a when searching for -lgcc /usr/local/bin/ld: cannot find -lgcc /usr/local/bin/ld: skipping incompatible /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd11.0/4.8.5/../../../libgcc_s. so when searching for -lgcc_s /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc_s.so when searching for -lgcc_s /usr/local/bin/ld: cannot find -lgcc_s /usr/local/bin/ld: skipping incompatible /lib/libc.so.7 when searching for /lib/libc.so.7 /usr/local/bin/ld: cannot find /lib/libc.so.7 /usr/local/bin/ld: skipping incompatible /usr/lib/libc_nonshared.a when searching for /usr/lib/libc_nonshared.a /usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a /usr/local/bin/ld: skipping incompatible /usr/lib/libssp_nonshared.a when searching for /usr/lib/libssp_nonshared.a /usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a collect2: error: ld returned 1 exit status -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Michael Matz Sent: lundi 24 octobre 2016 18:02 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup" Hi, On Thu, 20 Oct 2016, Christian Jullien wrote: > I'm sure you'll not believe me, but it's NOT an April Fool. > > $ uname -a > FreeBSD freebsd64.eligis.com 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 > #0 > r306420: Thu Sep 29 01:43:23 UTC 2016 > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 $ gcc > -m32 --print-file-name=crt1.o /usr/lib/crt1.o $ gcc -m64 > --print-file-name=crt1.o /usr/lib/crt1.o $ gcc > --print-file-name=crt1.o /usr/lib/crt1.o $ find /usr -name crt1.o > /usr/lib32/crt1.o /usr/lib/crt1.o Gnah! So they managed to break GCCs multi-lib support in subtle ways. Can you even build a hello world type program with "gcc -m32" on that system? Sigh. Okay, of course nothing is ever as simple :-/ :) Ciao, Michael. > > -Original Message- > From: Tinycc-devel > [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] > On Behalf Of Michael Matz > Sent: jeudi 20 octobre 2016 17:23 > To: tinycc-devel@nongnu.org > Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit > "configure: --triplet= option, Makefile: cleanup" > > Hello Christian, > > On Wed, 19 Oct 2016, Christian Jullien wrote: > > > x86_64: > > $ uname -m > > amd64 > > $ gcc --print-file-name=crt1.o > > /usr/lib/crt1.o > > $ find /usr -name crt1.o > > /usr/lib32/crt1.o > > /usr/lib/crt1.o > > Aha! So they chose the opposite way to the linuxes. Okay, that > helps, thanks. Can you verify that > > % gcc -m32 --print-file-name=crt1.o > > gives /usr/lib32/crt1.o ? > > > Ciao, > Michael. > > ___ > 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 > ___ 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] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Hi, On Thu, 20 Oct 2016, Christian Jullien wrote: > I'm sure you'll not believe me, but it's NOT an April Fool. > > $ uname -a > FreeBSD freebsd64.eligis.com 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 > r306420: Thu Sep 29 01:43:23 UTC 2016 > r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > $ gcc -m32 --print-file-name=crt1.o > /usr/lib/crt1.o > $ gcc -m64 --print-file-name=crt1.o > /usr/lib/crt1.o > $ gcc --print-file-name=crt1.o > /usr/lib/crt1.o > $ find /usr -name crt1.o > /usr/lib32/crt1.o > /usr/lib/crt1.o Gnah! So they managed to break GCCs multi-lib support in subtle ways. Can you even build a hello world type program with "gcc -m32" on that system? Sigh. Okay, of course nothing is ever as simple :-/ :) Ciao, Michael. > > -Original Message- > From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] > On Behalf Of Michael Matz > Sent: jeudi 20 octobre 2016 17:23 > To: tinycc-devel@nongnu.org > Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit > "configure: --triplet= option, Makefile: cleanup" > > Hello Christian, > > On Wed, 19 Oct 2016, Christian Jullien wrote: > > > x86_64: > > $ uname -m > > amd64 > > $ gcc --print-file-name=crt1.o > > /usr/lib/crt1.o > > $ find /usr -name crt1.o > > /usr/lib32/crt1.o > > /usr/lib/crt1.o > > Aha! So they chose the opposite way to the linuxes. Okay, that helps, > thanks. Can you verify that > > % gcc -m32 --print-file-name=crt1.o > > gives /usr/lib32/crt1.o ? > > > Ciao, > Michael. > > ___ > 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 > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
I'm sure you'll not believe me, but it's NOT an April Fool. $ uname -a FreeBSD freebsd64.eligis.com 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 $ gcc -m32 --print-file-name=crt1.o /usr/lib/crt1.o $ gcc -m64 --print-file-name=crt1.o /usr/lib/crt1.o $ gcc --print-file-name=crt1.o /usr/lib/crt1.o $ find /usr -name crt1.o /usr/lib32/crt1.o /usr/lib/crt1.o -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Michael Matz Sent: jeudi 20 octobre 2016 17:23 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup" Hello Christian, On Wed, 19 Oct 2016, Christian Jullien wrote: > x86_64: > $ uname -m > amd64 > $ gcc --print-file-name=crt1.o > /usr/lib/crt1.o > $ find /usr -name crt1.o > /usr/lib32/crt1.o > /usr/lib/crt1.o Aha! So they chose the opposite way to the linuxes. Okay, that helps, thanks. Can you verify that % gcc -m32 --print-file-name=crt1.o gives /usr/lib32/crt1.o ? Ciao, Michael. ___ 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] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Hi, On Tue, 18 Oct 2016, grischka wrote: > Honestly, in my book the cross compilers are just to test > compilation, they are not assumed to work out of the box. > (Except the windows compiles where everything you need comes > with the source and therefor is well known where it is). I generally sympathize with this, except for one case: where the cross compilers aren't really "cross" :) E.g. on my linux x86-64 system I'd expect x86_64-tcc and ./tcc be basically the same. Also the i386-tcc should be basically a native compiler that acts like gcc -m32. I agree that for e.g. ./arm-tcc on such system all bets are off. > There is no support whatsoever from our configure either. > People tried to "fix" that but I was not able to detect > any underlying concept. Right, there were only hacks over hacks that made it sort of work for most people :) I also agree that cleaning this up would be better. > As to the lib/lib64 issue, whatever you can figure out I'm fine. Okay, perhaps on the weekend. > Except I'd prefer to have the logic in only one location, that > is NOT in both the Makefile AND configure, because that is just > confusing. Yeah. > FYI: on my (old 8.10 from 2008) ubuntu 64, there is /usr/lib64, > but it is a link to /usr/lib. There is also /usr/lib/x86_64-linux-gnu, > but it is empty. I was under the impression that lib64 was an > old misguided concept from the early 64 bit days. Maybe I was wrong. Yeah, no, it wasn't really misguided. Simply the first approach to deal with a multi-arch system; at the time we did the x86-64 port there were already some systems that used similar models: ia64 with its /libx86, and Solaris with /usr/lib/64. Of course once you do something like that you're bound to never change it again because it'd break all userspace :-/ The debian multi-arch way was invented much later to solve a larger problem (that of _really_ having cross architecture libs on one system). The debian based distros eventually picked this up (though, of course, the older /lib64 way is still supported), the rpm based ones didn't bother. I'll try to come up with something. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Hello Christian, On Wed, 19 Oct 2016, Christian Jullien wrote: > x86_64: > $ uname -m > amd64 > $ gcc --print-file-name=crt1.o > /usr/lib/crt1.o > $ find /usr -name crt1.o > /usr/lib32/crt1.o > /usr/lib/crt1.o Aha! So they chose the opposite way to the linuxes. Okay, that helps, thanks. Can you verify that % gcc -m32 --print-file-name=crt1.o gives /usr/lib32/crt1.o ? Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Let me summarize where we are on FreeBSD i386 and x86_64 with mod: x86_64: $ uname -m amd64 $ gcc --print-file-name=crt1.o /usr/lib/crt1.o $ find /usr -name crt1.o /usr/lib32/crt1.o /usr/lib/crt1.o $ ./configure Binary directory /usr/local/bin TinyCC directory/usr/local/lib/tcc Library directory /usr/local/lib Include directory /usr/local/include Manual directory/usr/local/share/man Info directory /usr/local/share/info Doc directory /usr/local/share/doc Target root prefix - Source path /usr/home/jullien/tinycc C compiler gcc Target OS FreeBSD CPU x86-64 Big Endian no Profiling no Cross compilers no Use libgcc no Triplet - Compiles but test produces: gmake -C tests gmake[1]: Entering directory '/usr/home/jullien/tinycc/tests' hello-exe ../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello || (../tcc -vv; exit 1) && ./hello Segmentation fault (core dumped) i386: $ uname -m i386 $ gcc --print-file-name=crt1.o /usr/lib/crt1.o $ find /usr -name crt1.o /usr/lib/crt1.o $ ./configure Binary directory /usr/local/bin TinyCC directory/usr/local/lib/tcc Library directory /usr/local/lib Include directory /usr/local/include Manual directory/usr/local/share/man Info directory /usr/local/share/info Doc directory /usr/local/share/doc Target root prefix - Source path /home/jullien/tinycc C compiler gcc Target OS FreeBSD CPU x86 Big Endian no Profiling no Cross compilers no Use libgcc no Triplet - Compiles but test produces: gmake -C tests gmake[1]: Entering directory '/usr/home/jullien/tinycc/tests' hello-exe ../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello || (../tcc -vv; exit 1) && ./hello Hello World hello-run ../tcc -B.. -I../include -I.. -I.. -run ../examples/ex1.c Hello World gcc -o libtcc_test libtcc_test.c ../libtcc.a -I.. -I.. -lm libtest ./libtcc_test -B.. -I../include -I.. -I.. Hello World! fib(32) = 2178309 add(32, 64) = 96 gcc -o tcctest.gcc tcctest.c -DTCC_TARGET_I386 -I.. -I.. -w -O0 -std=gnu99 -fno-omit-frame-pointer ./tcctest.gcc > test.ref test3 ../tcc -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -I../include -I.. -I.. -run tcctest.c > test.out3 tcc: error: undefined symbol 'memcpy' tcc: error: undefined symbol 'strlen' tcc: error: undefined symbol 'memmove' tcc: error: undefined symbol 'memset' tcc: error: undefined symbol 'memcmp' -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of grischka Sent: mardi 18 octobre 2016 18:50 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup" Michael Matz wrote: > Hmm and now I see that this hunk also generally breaks building the > target compilers like x86_64-tcc, because they don't get > NATIVE_DEFINES from config.mak, and hence no -DCONFIG_LDDIR even if > configure would have found the correct one, so it now defaults to /lib, and boom. Hi Michael, Honestly, in my book the cross compilers are just to test compilation, they are not assumed to work out of the box. (Except the windows compiles where everything you need comes with the source and therefor is well known where it is). There is no support whatsoever from our configure either. People tried to "fix" that but I was not able to detect any underlying concept. As I see it, if you want cross-compilers that really work you need to edit/add the CONFIG_TCC_ paths for that target manually in the Makefile (which is not difficult at all) or pass via environment or something. (We could maybe add a "cross-config-include.mak.template" as an example). As to the lib/lib64 issue, whatever you can figure out I'm fine. Except I'd prefer to have the logic in only one location, that is NOT in both the Makefile AND configure, because that is just confusing. FYI: on my (old 8.10 from 2008) ubuntu 64, there is /usr/lib64, but it is a link to /usr/lib. There is also /usr/lib/x86_64-linux-gnu, but it is empty. I was under the impression that lib64 was an old misguided concept from the early 64 bit days. Maybe I was wrong. Thanks, -- grischka ___ Tinycc-devel mailing list <mailto:Tinycc-devel@nongnu.org> Tinycc-devel@nongnu.org <https://lists.n
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Michael Matz wrote: Hmm and now I see that this hunk also generally breaks building the target compilers like x86_64-tcc, because they don't get NATIVE_DEFINES from config.mak, and hence no -DCONFIG_LDDIR even if configure would have found the correct one, so it now defaults to /lib, and boom. Hi Michael, Honestly, in my book the cross compilers are just to test compilation, they are not assumed to work out of the box. (Except the windows compiles where everything you need comes with the source and therefor is well known where it is). There is no support whatsoever from our configure either. People tried to "fix" that but I was not able to detect any underlying concept. As I see it, if you want cross-compilers that really work you need to edit/add the CONFIG_TCC_ paths for that target manually in the Makefile (which is not difficult at all) or pass via environment or something. (We could maybe add a "cross-config-include.mak.template" as an example). As to the lib/lib64 issue, whatever you can figure out I'm fine. Except I'd prefer to have the logic in only one location, that is NOT in both the Makefile AND configure, because that is just confusing. FYI: on my (old 8.10 from 2008) ubuntu 64, there is /usr/lib64, but it is a link to /usr/lib. There is also /usr/lib/x86_64-linux-gnu, but it is empty. I was under the impression that lib64 was an old misguided concept from the early 64 bit days. Maybe I was wrong. Thanks, -- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Hi, On Tue, 18 Oct 2016, avih wrote: > Some time ago I also bumped into the lib64 issue, which was apparent > when building cross compilers on a 64 system which doesn't use lib64, > e.g. Ubuntu 64. At the time I wrote a patch (which I didn't submit to > mob) which decides only at one place (configure) and then uses it > everywhere else.That's the patch: > https://github.com/avih/tinycc/commit/65b39fb66657459339fac88f1f4f4cedca4d0ad1 See my follow up, that's not a complete solution either because the $target-tcc compilers aren't build with NATIVE_DEFINES. There are three major ways of dealing with multi-lib systems: 1 no multi-lib at all. subcases: a) 64-bit only into /lib64 b) 64-bit only but into /lib 2 restricted multi-lib, 32-bit or 64-bit at least non-debian linuxes: a) 64-bit to /lib64, 32-bit to /lib, 64-bit considered "native" b) 64-bit to /lib, 32-bit to /lib32, 64-bit considered "native" 3 unrestricted multi-lib, aka multiarch debian linuxes: everything to /usr/$triplet/lib I don't know about the *BSDs, but probably they fit one of the above. The way to find out which directory is used by gcc when calling without options (i.e. the default) is to inspect the output of % gcc --print-file-name=crt1.o The second to last component will be the libdir name. The full path could also be used. > However, with recent clean mob (though I haven't tested with the very > latest 2-3 commits as of now) Yeah, it's the (as of now) most recent commit that broke it :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Can we just take a moment to appreciate how a pull request with automated testing (a la Travis CI) would have made this error obvious *before* it was added to mob? On Tue, Oct 18, 2016 at 11:09 AM, Michael Matzwrote: > Hi, > > On Tue, 18 Oct 2016, grischka wrote: > > > Christian Jullien wrote: > > > Get worse as it now core dumps ... > > > > At least it seems to find the crt*.o now. > > But not on linux-x86-64 anymore :-/ I think trying to fix things for a > system one doesn't have access to is futile. FWIW, your recent patch did, > amongst other things: > > #ifndef CONFIG_LDDIR > -# ifdef TCC_TARGET_X86_64 > -# define CONFIG_LDDIR "lib64" > -# else > -# define CONFIG_LDDIR "lib" > -# endif > +# define CONFIG_LDDIR "lib" > #endif > > Okay, so no sensible default setting anymore, which is fine, but now we > rely on configure providing the correct one. But the same commit also > does: > > - triplet="$($CONFTEST triplet)" > - if test -f "/usr/lib/$triplet/crti.o" ; then > - tcc_lddir="lib" > - multiarch_triplet="$triplet" > - elif test "$cpu" != "x86" -a -f "/usr/lib64/crti.o" ; then > - tcc_lddir="lib64" > + > + if test -z "$triplet"; then > +tt="$($CONFTEST triplet)" > +if test -n "$tt" -a -f "/usr/lib/$tt/crti.o" ; then > + triplet="$tt" > +fi > + fi > + > + if test -z "$triplet"; then > +if test ! -f "/usr/lib/crti.o" -a -f "/usr/lib64/crti.o" ; then > + tcc_lddir="lib64" > +fi >fi > > That's not correct. On an x86-64 system I can have both /usr/lib/crti.o > and /usr/lib64/crti.o, namely when one also has a 32bit development > environment (which I have). Before it was testing if the cpu isn't x86 > and differenciated by that. Now, on my system, tcc_lddir remains unset > and hence runs into the above hunk which has no fallback to lib64 anymore. > > Christian: do you have /usr/lib64 as well or only /usr/lib? If you also > have the former, is there a crti.o in there as well? > > I'm tempted to remove the check for /usr/lib/crti.o altogether. That > would mean to always assume lib64 if no triplet is given but > /usr/lib64/crti.o exists. That seems sensible to me (on 32 hosts you > won't have lib64, and on 64bit hosts you probably will default to 64bit > code). > > Thoughts? > > > Ciao, > Michael. > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Hi, On Tue, 18 Oct 2016, Michael Matz wrote: > But not on linux-x86-64 anymore :-/ I think trying to fix things for a > system one doesn't have access to is futile. FWIW, your recent patch did, > amongst other things: > > #ifndef CONFIG_LDDIR > -# ifdef TCC_TARGET_X86_64 > -# define CONFIG_LDDIR "lib64" > -# else > -# define CONFIG_LDDIR "lib" > -# endif > +# define CONFIG_LDDIR "lib" > #endif Hmm and now I see that this hunk also generally breaks building the target compilers like x86_64-tcc, because they don't get NATIVE_DEFINES from config.mak, and hence no -DCONFIG_LDDIR even if configure would have found the correct one, so it now defaults to /lib, and boom. Hmm. The state before was arguably broken as well, but in practice less broken than now :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Hi, On Tue, 18 Oct 2016, grischka wrote: > Christian Jullien wrote: > > Get worse as it now core dumps ... > > At least it seems to find the crt*.o now. But not on linux-x86-64 anymore :-/ I think trying to fix things for a system one doesn't have access to is futile. FWIW, your recent patch did, amongst other things: #ifndef CONFIG_LDDIR -# ifdef TCC_TARGET_X86_64 -# define CONFIG_LDDIR "lib64" -# else -# define CONFIG_LDDIR "lib" -# endif +# define CONFIG_LDDIR "lib" #endif Okay, so no sensible default setting anymore, which is fine, but now we rely on configure providing the correct one. But the same commit also does: - triplet="$($CONFTEST triplet)" - if test -f "/usr/lib/$triplet/crti.o" ; then - tcc_lddir="lib" - multiarch_triplet="$triplet" - elif test "$cpu" != "x86" -a -f "/usr/lib64/crti.o" ; then - tcc_lddir="lib64" + + if test -z "$triplet"; then +tt="$($CONFTEST triplet)" +if test -n "$tt" -a -f "/usr/lib/$tt/crti.o" ; then + triplet="$tt" +fi + fi + + if test -z "$triplet"; then +if test ! -f "/usr/lib/crti.o" -a -f "/usr/lib64/crti.o" ; then + tcc_lddir="lib64" +fi fi That's not correct. On an x86-64 system I can have both /usr/lib/crti.o and /usr/lib64/crti.o, namely when one also has a 32bit development environment (which I have). Before it was testing if the cpu isn't x86 and differenciated by that. Now, on my system, tcc_lddir remains unset and hence runs into the above hunk which has no fallback to lib64 anymore. Christian: do you have /usr/lib64 as well or only /usr/lib? If you also have the former, is there a crti.o in there as well? I'm tempted to remove the check for /usr/lib/crti.o altogether. That would mean to always assume lib64 if no triplet is given but /usr/lib64/crti.o exists. That seems sensible to me (on 32 hosts you won't have lib64, and on 64bit hosts you probably will default to 64bit code). Thoughts? Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Thanks, no more core dump but still unable to link with std C. $ ./tcc -vv tcc version 0.9.26 (i386 FreeBSD) install: /usr/local/lib/tcc include: /usr/local/lib/tcc/include /usr/local/include /usr/include libraries: /usr/lib /lib /usr/local/lib crt: /usr/lib elfinterp: /libexec/ld-elf.so.1 $ gmake test gmake -C tests gmake[1]: Entering directory '/usr/home/jullien/tinycc/tests' hello-exe ../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello || (../tcc -vv; exit 1) ./hello Hello World hello-run ../tcc -B.. -I../include -I.. -I.. -run ../examples/ex1.c Hello World gcc -o libtcc_test libtcc_test.c ../libtcc.a -I.. -I.. -lm libtest ./libtcc_test -B.. -I../include -I.. -I.. Hello World! fib(32) = 2178309 add(32, 64) = 96 gcc -o tcctest.gcc tcctest.c -DTCC_TARGET_I386 -I.. -I.. -w -O0 -std=gnu99 -fno-omit-frame-pointer ./tcctest.gcc test.ref test3 ../tcc -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. -I../include -I.. -I.. -run tcctest.c test.out3 tcc: error: undefined symbol 'memcpy' tcc: error: undefined symbol 'strlen' tcc: error: undefined symbol 'memmove' tcc: error: undefined symbol 'memset' tcc: error: undefined symbol 'memcmp' ... All other tests passed! - message d'origine - De : "grischka" gris...@gmx.de date mar. 18/10/2016 15:05 (GMT +02:00) À : "tinycc-devel@nongnu.org" tinycc-devel@nongnu.org Objet : Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup" Christian Jullien wrote: Get worse as it now core dumps ... At least it seems to find the crt*.o now. See also http://lists.gnu.org/archive/html/tinycc-devel/2009-11/msg7.html http://lists.gnu.org/archive/html/tinycc-devel/2009-11/msg9.html http://lists.gnu.org/archive/html/tinycc-devel/2009-11/msg00010.html The mentioned commit is now: http://repo.or.cz/w/tinycc.git/commitdiff/55cb2170cd5ce77 From +*paddr = uc-uc_mcontext.mc_rip; it seems the patch was for x86-64. -- gr ___ 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
[Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Hi Grischka, This one tccpp_new/delete and other cleanups commit 0be098929a062d706057d7beb78666daa52bac49 still works on FreeBSD with of course C library not found as previously reported But next commit configure: --triplet= option, Makefile: cleanupmob commit 02919cd27506e25dacdbe72dad1ae2718eb75991 Get worse as it now core dumps (I notice that Triplet is empty, is it wanted?): $ ./configure Binary directory /usr/local/bin TinyCC directory/usr/local/lib/tcc Library directory /usr/local/lib Include directory /usr/local/include Manual directory/usr/local/share/man Info directory /usr/local/share/info Doc directory /usr/local/share/doc Target root prefix - Source path /home/jullien/tinycc C compiler gcc Target OS FreeBSD CPU x86-64 Big Endian no Profiling no Cross compilers no Use libgcc no Triplet - Creating config.mak and config.h ... gmake test $ gmake test gmake -C tests gmake[1]: Entering directory '/usr/home/jullien/tinycc/tests' hello-exe ../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello || (../tcc -vv; exit 1) && ./hello Segmentation fault (core dumped) tcc version 0.9.26 (x86-64 FreeBSD) install: /usr/local/lib/tcc include: /usr/local/lib/tcc/include /usr/local/include /usr/include libraries: /usr/lib /lib /usr/local/lib crt: /usr/lib elfinterp: /libexec/ld-elf.so.1 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel