I tried to compile tcc for ARM using gcc 4.6.3 . but I got following error while compiling in both shared/static lib mod :
root#localhost:/p/tcc/tcc# make
gcc -o tcc tcc.o libtcc.so.1.0 -lm -ldl -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -D_FORTIFY_SOURCE=0 -Wl,-rpath,"/usr/local/lib" libtcc.so.1.0: undefined reference to `vrotb'
collect2: ld returned 1 exit status
make: *** [tcc] Error 1
I am using lastest branch from tcc github
Just checked it on raspberry pi (ARMv6 CPU). https://github.com/TinyCC/TinyCC repository, removed static qualifier from vrotb function in tccgen.c (line 945). It builds and passes 'hello world'.
Since that's obvious mistake likely to be introduced by some change that they forgot to adapt for ARM - i suggest performing further tests to ensure it works as intended. Bug report should be filed - probably on github.
I know it is little confusing, but your problem is that you are using wrong repository. Fabrice Bellard does not work any more on TinyCC (see http://bellard.org/tcc/). He keeps his repositories for personal/historical reasons. However all development has moved to http://repo.or.cz/w/tinycc.git. To confuse things even more the 0.9.26 release from Fabrice's web site is actually from the http://repo.or.cz/w/tinycc.git repository, and not Fabrice's own. But this is all just communication issue. In short you should use new repository. On the repository web site is a link to a mailing list where you should report any problems in case the new repo code does not compile.
Related
I am looking to develop a d3d11 app with gcc from tdm-gcc(tried pure MinGW didn't work), I've written test app, but am unable to link libd3d11 in order to get D3D11CreateDeviceAndSwapChain#48
The app is supposed to be compileable in both 32-bit and 64-bit respectively.
Here's how I compile trying to use mingw headers and libs:
gcc -m32 -ld3d11 main.c -o test.exe
I am getting:
C:/MinGW/64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\TEMP\ccvsC3nh.o:main.c:(.text+0x243): undefined reference to `D3D11CreateDeviceAndSwapChain#48'
collect2.exe: error: ld returned 1 exit status
I've seen some posts about compiling directx via mingw, but they didn't give sufficient info, as I am not exactly sure what I am missing or doing wrong.
I am trying to recompile binutils and GCC as a cross-compiler for m68k architecture. I am following these instructions:
http://darkdust.net/writings/megadrive/crosscompiler
However, the process keeps failing on one part or another. I have tried with binutils 2.16.1 and gcc 3.4.6, binutils 2.15 and gcc 3.4.2 and binutils 2.15 and gcc 3.4.6.
This last attempt fails when running "make" on gcc, after making and installing binutils. It gives the following error:
gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H
-I. -I. -I../../gcc-3.4.2/gcc -I../../gcc-3.4.2/gcc/. -I../../gcc-
3.4.2/gcc/../include \
-DTARGET_MACHINE=\"m68k-coff\" \
-c ../../gcc-3.4.2/gcc/collect2.c -o collect2.o
In file included from /usr/include/fcntl.h:289:0,
from ../../gcc-3.4.2/gcc/system.h:214,
from ../../gcc-3.4.2/gcc/collect2.c:30:
In function ‘open’,
inlined from ‘collect_execute’ at ../../gcc-3.4.2/gcc/collect2.c:1535:20:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to
‘__open_missing_mode’ declared with attribute error: open with O_CREAT or
O_TMPFILE in second argument needs 3 arguments
__open_missing_mode ();
^
Makefile:1364: recipe for target 'collect2.o' failed
make[1]: *** [collect2.o] Error 1
make[1]: Leaving directory '/home/gabriel/src/gcc-build/gcc'
Makefile:23339: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
I don't expect to fix this error, but does anyone know of a combination of binutils and gcc release that work? Should I be using a certain version of gcc to recompile gcc successfuly?
Thanks for any insight you may have on this!
EDIT:
My linux has GCC 5.4.0 so I just downloaded the 5.4.0 source to try and rebuild that for m68k cross-compiling. I now get the following error when running "make" on the gcc source:
*** Configuration m68k-unkown-coff not supported
What could be the cause of this? Is it because I need an older version of GCC? (the binutils version i'm using definately supports the m68k target). The tutorial I'm using always defines "--target=m68k-coff", should that instead be "--target=m68k-unkown-coff"?
EDIT 2:
So I tried compiling for m68k-elf but now I get this error:
checking for m68k-elf-gcc... /home/gabriel/src/gcc-build/./gcc/xgcc -B/home/gabriel/src/gcc-build/./gcc/ -B/opt/m68k/m68k-elf/bin/ -B/opt/m68k/m68k-elf/lib/ -isystem /opt/m68k/m68k-elf/include -isystem /opt/m68k/m68k-elf/sys-include
checking for suffix of object files... configure: error: in `/home/gabriel/src/gcc-build/m68k-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
I ran download_prerequisites before building so it should not be a problem with the MPC library. Any idea how to move on? I need assembler only so I don't mind what the format of the object files is. Thanks!
I used to do pretty much what you are doing right now.
My advice is to use crosstool-ng (http://crosstool-ng.github.io), as it does pretty much everything in an automated manner.
If you are studying m68k assembly, I used to host a modified version of gcc-explorer by Matt Godbolt (https://godbolt.org/). You can find a runnable docker image here (https://hub.docker.com/r/esantoro/acso-explorer/) and some more details here (https://znpy.wordpress.com/2017/05/08/decommisioning-acso-explorer-santoro-tk/)
Hope it helps,
znpy
you can build most versions with a current Linux. To install the prerequisites have a look at https://github.com/bebbo/amiga-gcc
unpack the gcc archive, e.g. to /opt/cross/gcc-6.5.0
create a separate build folder, e.g. /opt/cross/xcc-6.5.0 - never build inside gcc's source folder!
create the prefix folder, that's where binaries are installed to, e.g. /opt/cross/gcc65
ensure that these folders exist and are writable, then
configure from within that build folder using an absolute path for configure
cd /opt/cross/xcc-6.5.0/
/opt/cross/gcc-6.5.0/configure --target=m68k-elf --program-prefix=m68k-elf- --enable-languages=c,c++ --prefix=/opt/cross/gcc65 --disable-libssp --disable-nls --disable-multilib
make all-gcc
make install-gcc
I'm also running the compiler explorer for 68k gccs at https://franke.ms/cex/
I'm currently trying to compile Clang/LLVM for a bare metal aarch64 target. Compiling Clang was straightforward - in fact I have compiled to target multiple architectures including arm and aarch64. For the backend I'm using binutils. Since binutils can only target one architecture I've built both aarch64 and arm versions of this. Again building seemed to be straightforward. I built binutils for aarch64 using:
mkdir build
cd build
../configure --target=aarch64-none-elf
make
from an unpacked source package of binutils 2.24.
The problem I'm having is that I can't get my custom build of ld to handle archive files properly. It seems to find and open archive files without a problem but fails to search it for undefined symbols when compiling the final binary. Here's some more concrete details via an example:
Create a simple main.s file by compiling:
int foo();
int main() { return foo(); }
with Clang and using --target=aarch64 -S, i.e. to emit an architecture specific assembly file.
Do the same to create foo.s by compiling:
int foo() { return 0; }
Assemble both .s files to .o files using custom gas build from binutils.
Create an archive libfoo.a by running custom ar and ranlib builds from binutils using ar cr foo.a foo.s and ranlib libfoo.a.
Try to link the two files together using ld -L. -lfoo -o main.elf main.o.
The output shows an undefined reference to foo.
bar.cpp:(.text+0x14): undefined reference to `foo()'
I can run readelf on foo.a and it seems perfectly well formed. In particular I can see the public symbol for foo. If I run ld with --verbose then I see
attempt to open ./libfoo.a succeeded
but no indication that it's found any symbols.
If I link directly with the object files, i.e. using ld -o main.elf foo.o main.o then I get a well formed elf file. Furthermore, if I extract foo.o back out of libfoo.a then I can also link succesfully with the extracted foo.o.
Does anyone have any ideas why this might be happening? I'm pretty sure my clang build is okay as the emitted assembly files effectively decouple the problem from clang. I'd guess also that the assembled .o files are fine. So this only leaves ar/ranlib or ld as the culprit.
To try to eliminate ar/ranlib as the culprits I rebuilt binutils for arm (same steps but using --target=arm-none-eabi). If I integrate the built ar/ranlib binaries into a known good arm-eabi-none GCC toolchain then they seem to work correctly. My suspicions thus point to ld at the moment. Note that I get the same problem with the main/foo example as above if I use my Clang build with the arm build of binutils.
I also tried integrating the arm version of ld into the existing known good GCC toolchain, but got:
this linker was not configured to use sysroots
Need to figure that out. That's still a bit cryptic for me right now. It prevents me from sanity checking the arm ld build.
It might well be that I'm doing something obviously wrong, but right now I don't see it.
Notes:
I had to hack the make script for binutils to add a couple of -Wno-xxx flags. I need to do this the "correct" way, but I don't think this hack should affect the output.
I'm building/hosting all tools on OSX 10.9.4 64-bit.
UPDATE:
The error about sysroots is simple. The pre-existing toolchain was configured with flags:
--with-prefix $SOME_INSTALL_DIR
--with-sysroot $SOME_INSTALL_DIR/arm-none-eabi
If I rebuild with these then I can slot in my ld version without a problem and it works. I got excited thinking that this might have been my mistake. Previously I wasn't running make install as I didn't really care about installing at this stage. I thought perhaps my new build of ld was referencing OSX system libs/exes somehow (although I'm not sure exactly what it could reference, other than perhaps ar, i.e. if it runs ar to handle archives). However I still have the same problem with both the arm and arrach64 versions of binutils even when configured like this.
Looks like I was dramatically overthinking the problem and also missing something I'd never quite realised about ld. The issue was with the line:
ld -L. -lfoo -o main.elf main.o
I hadn't realise that ld is sensitive to object file/library ordering. The undefined reference to foo() was in main.o. I specified the library libfoo.a as input before main.o is parsed. This means that the linker doesn't bother searching libfoo.a for the symbol as it's already processed this library. main.o must be specified before, e.g.
ld -L. main.o -lfoo -o main.elf
Even wrapping -lfoo with --start-group ... --end-group doesn't fix this.
I'm still feeling somewhat surprised by this. And I've yet to convince myself it's a good feature of ld. Seems like the only use case I can think of right now is to sneakily allow duplicate symbols.
Time for a cup of tea!
I recently discovered the Tiny C Compiler. For the project that I'm currently working on, performance is not a real issue, but file size is, making TCC ideal. I'm using Autotools as a build manager, and I figured that using TCC would be as simple as ./configure CC=tcc.
However, this returns checking whether the C compiler works... no. In config.log, it says configure: exit 77.
Despite all of this, setting CC=clang works fine. Is there any way to get Autotools to use TCC?
The issue appears to have been the fault of my CFLAGS. While TCC was normally able to compile programs with them, Autotools seems to have thought otherwise. Setting CFLAGS="" resolved the issue.
For future reference, my CFLAGS are -march=native -mtune=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4.
iirc tcc does not produce tiny executables - it is tcc itself that is tiny. Perhaps you're looking for gcc -Os?
I am trying to install pngnq, which relies on libpng >= 1.2.8. I have installed libpng 1.5.7 via ./configure, make, sudo make install (without problems), because the libpng version in the Software Center was too old. I am now trying to install pngnq via ./configure, make, sudo make install (again, because Software Center version is too old), but am getting stuck at the make step on error messages which I believe pertain to libpng linking. A small sample of the error messages:
undefined reference to `png_destroy_write_struct'
undefined reference to `png_convert_from_time_t'
undefined reference to `png_set_PLTE'
I have limited experience with installing software manually on Linux, and so am not really sure what the next step is in diagnosing the problem. I've done substantial searching, but haven't really found anything targeted at the issue I'm having. Based on a forum post on a similar-ish issue I've done an ls on /usr/local/lib directory and found:
libpng15.a libpng15.so.15 libpng.la libpng15.la
libpng15.so.15.7.0 libpng.so libpng15.so libpng.a
though I don't know if that's actually any use in diagnosing/ruling out certain problems. Can anyone advise what might be wrong, keeping in my my minimal experience with compiling code on Linux?
Edit:
As requested, here is a sample of the trace beginning at the make call:
bryce#whatever:~/Downloads/pngnq-1.1$ make
Making all in src
make[1]: Entering directory `/home/bryce/Downloads/pngnq-1.1/src'
make all-am
make[2]: Entering directory `/home/bryce/Downloads/pngnq-1.1/src'
gcc `libpng-config --I_opts` -Wall --pedantic -std=gnu99 -g -O2 `libpng-config
--ldflags` -lz -o pngnq pngnq.o neuquant32.o rwpng.o -lm -lz
pngnq.o: In function `pngnq':
/home/bryce/Downloads/pngnq-1.1/src/pngnq.c:518: undefined reference to `png_get_gAMA'
Sounds like includes don't match the library. Double check to see if you've got png.h in /usr/include or libpng* in /usr/lib/.
Also show the gcc line that shows up before you see the error. That might point to the issue.