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:

-# ifdef TCC_TARGET_X86_64
-#   define CONFIG_LDDIR "lib64"
-# else
-#   define CONFIG_LDDIR "lib"
-# endif
+# define CONFIG_LDDIR "lib"

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 

-      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

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 



Tinycc-devel mailing list

Reply via email to