Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

2016-10-24 Thread Christian Jullien
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"

2016-10-24 Thread Michael Matz
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"

2016-10-20 Thread Christian Jullien
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"

2016-10-20 Thread Michael Matz
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"

2016-10-20 Thread Michael Matz
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"

2016-10-18 Thread Christian Jullien
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"

2016-10-18 Thread grischka

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"

2016-10-18 Thread Michael Matz
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"

2016-10-18 Thread David Mertens
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 Matz  wrote:

> 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"

2016-10-18 Thread Michael Matz
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"

2016-10-18 Thread Michael Matz
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"

2016-10-18 Thread Christian JULLIEN
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"

2016-10-17 Thread Christian Jullien
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