[Top][All Lists]

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

Re: [Tinycc-devel] --enable-cross and libtcc1.a

From: avih
Subject: Re: [Tinycc-devel] --enable-cross and libtcc1.a
Date: Sun, 26 Feb 2017 13:52:11 +0000 (UTC)

I figured it out. Commit bb93064 changed a path separator from colon to semicolon, which effectively removed the previous global path while running the tests.

Pushed a fix to mob as "2da3673  win: tests Makefile: fix global path".

On Saturday, February 25, 2017 6:30 PM, avih <address@hidden> wrote:

Thanks. The unification in the last commit is nice IMHO but I think it broke something with the tests or the path during the tests or something with the recursive make invocation.

In mingw-32 env of MSYS2 (with gcc mingw 32), when configuring without --enable-cross, make succeeds, but make test fails with the following:

make[1]: Entering directory '<path/to/tcc>/bld/tests'
------------ hello-exe ------------
../tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. ../../tests/../examples/ex1.c -o hello.exe || (../tcc -vv; exit 1) && ./hello.exe
<path/to/tcc>/bld/tcc.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
<path/to/tcc>/bld/tcc.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
make[1]: *** [Makefile:71: hello-exe] Error 1
make[1]: Leaving directory '<path/to/tcc>/bld/tests'
make: *** [Makefile:342: test] Error 2

If adding --enable-static to configure, then make test goes a bit further but still fails:

make[1]: Entering directory '<path/to/tcc>/bld/tests'
------------ hello-exe ------------
../tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. ../../tests/../examples/ex1.c -o hello.exe || (../tcc -vv; exit 1) && ./hello.exe
Hello World
------------ hello-run ------------
../tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. -run ../../tests/../examples/ex1.c
Hello World
gcc -o libtcc_test.exe ../../tests/libtcc_test.c ../libtcc.a -fno-strict-aliasing -I.. -I../..
/tmp/ccXipLP9.o:libtcc_test.c:(.text+0x29): undefined reference to `tcc_new'
/tmp/ccXipLP9.o:libtcc_test.c:(.text+0x29): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `tcc_new'
< and several more errors with undefined references and relocation truncation>

If using --cc=<path/to/existing-static/tcc.exe> in configure instead of gcc, then the tests succeed (still in MSYS2's mingw 32 env).

Outside of MSYS2, until before the last commit I was also able to use MSYS(1) environment/shell which has 'make' but no gcc (so using --cc=/path/to/tcc.exe), but with the last commit the tests fail now (after build succeeds):

make -C tests
make[1]: Entering directory `</path/to/tcc>/bld/tests'
make[1]: make: Command not found
make[1]: *** [clean-s] Error 127
make[1]: Leaving directory `</path/to/tcc>/bld/tests'
make: *** [test] Error 2

On Thursday, February 23, 2017 9:54 AM, grischka <address@hidden> wrote:

Ok, I added compilation of more libtcc1-xxx.a targets and a
pseudo (hex-code) assembler for arm also.

It's now even possible to configure really working cross-compilers.
Ic you know how ;)

-- gr

avih wrote:
> 1. Immediate issue:On windows, when building using a native 64 bit compiler, e.g. using:> mkdir bld && cd bld && configure ../ --cpu=x86-64 --enable-cross && make && make install
> I get the following error during install, which is ignored (`make install` returns a success code):> install -m644 lib/x86_64-win32/libtcc1.a <prefix>"/lib/64"
>> install: cannot stat `lib/x86_64-win32/libtcc1.a': No such file or directory> make: [install] Error 1 (ignored)
> And when building with a 32 bit compiler then the equivalent 32 bit libtcc1.a is missing.
> While it's not critical since we have the native version anyway which is equivalent, having this error is not nice.
> It's possible to just skip the native-variant cross build installl, but I think it would be simpler to just build all the cross progs, which then installs successfully. The native and cross progs and libs (for the same platform) don't clash as far as I can tell, so it doesn't hurt to just build and install all of them. It also helps that the Makefile has less exceptions, e.g. this patch solves it (note that it also adds $(I386_CROSS) which I think is accidentally missing):
> diff --git a/Makefile b/Makefile
> index 00d17bb..81b652d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -97,13 +97,11 @@ C67_FILES = $(CORE_FILES) c67-gen.c c67-link.c tcccoff.c
>  ifdef CONFIG_WIN32
>  ifeq ($(ARCH),x86_64)
> -  LIBTCC1_CROSS=lib/i386-win32/libtcc1.a
>  else
> -  LIBTCC1_CROSS=lib/x86_64-win32/libtcc1.a
>  endif
> +LIBTCC1_CROSS=lib/i386-win32/libtcc1.a lib/x86_64-win32/libtcc1.a
>  else ifeq ($(ARCH),i386)
> 2. In general, it seems that libtcc1.a for the cross progs is only built for the windows progs, and only on x86[_64] platforms. E.g. on arm, $(CROSS_PROGS) includes the windows compilers but not their libtcc1.a, and on linux 64 there's no libtcc1.a for linux 32.
> It's not entirely clear to me if libtcc1.a can be built for all the cross progs, but it does seem to me that all of them need it, and it probably cannot be expected to be available as part of the native toolchain of the cross target.
> E.g. create a minimal c program with main which just returns 0 and try to compile it with all the cross compilers. All of them complain of a missing libtcc1.a (except for windows, if the native platform is x86[-64]), and most of them also complain on few missing crt?.o and libc.
> E.g. on Ubuntu 64, trying to use i386-tcc to compile the test program results in (some real path shows at <prefix>):
> tcc: error: file 'crt1.o' not found
> tcc: error: file 'crti.o' not found
> tcc: error: library 'c' not found
> tcc: error: file <prefix>'/lib/tcc/i386/libtcc1.a' not found
> tcc: error: file 'crtn.o' not found
> I'd think that if it's possible to build libtcc1.a for more platforms, then a patch similar to the above but even more general could be useful. I.e. use as little exceptions as possible, e.g. on i386 also build cross i386, etc. It might be even possible to use the exact same set of cross progs and cross libs regardless of the host.
> However, trying the above just for linux and windows, it seems that install still doesn't copy all of them, so maybe that could be generalized too.

> ------------------------------------------------------------------------
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

reply via email to

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