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
