tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --t


From: Michael Matz
Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"
Date: Tue, 18 Oct 2016 17:09:55 +0200 (CEST)
User-agent: Alpine 2.20 (LSU 67 2015-01-07)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]