I am trying to compile a plugin for Stata (a statistical programming language) that is written in C. Its author was able to compile it on other machines using the following commands on a 32-bit PC Windows (using Cygwin):
gcc -shared -mno-cygwin stplugin.c strgroup.c -O3 -funroll-loops -o strgroup.PC.Windows.plugin
He was also able to compile it on 64-bit Unix with:
gcc -shared -fPIC -DSYSTEM=OPUNIX stplugin.c strgroup.c -O3 -funroll-loops -o "strgroup.PC (64-bit x86-64).Unix.plugin"
And Macintosh OS X with:
gcc -bundle -arch i386 -arch x86_64 -arch ppc -DSYSTEM=APPLEMAC stplugin.c strgroup.c -O3 -funroll-loops -o "strgroup.Macintosh.MacOSX.plugin"
I am trying to compile it on 64-bit Windows 7 machine using Cygwin 1.7.9-1 and gcc v4.5.3. The mno-cygwin flag is giving me trouble, but I am not able to figure out how to use a mingw-targeted cross-compiler.
The -mno-cygwin option is no longer supported.
Install either of the mingw-*, mingw64-i686-* or mingw64-x86_64-* toolchain (category Devel in the Cygwin package manager) to get a proper cross-compiler.
Related
I just set-up GNU gcc on my Mac through some re-organization of my path and builds so it's not an alias for clang anymore. Running gcc -g, I expect debugging symbols to be self-contained within the executable, but they are still generating the .dSYM. How can I get the behavior I expect instead of the .dSYM folder, which I believe comes from Xcode command line tools?
I am specifically running:
gcc -O3 -g3 -Wall -Wextra -fanalyzer -march=native -mtune=native -mrdrnd
but this behavior even occurs with basic gcc -g hello.c -o hello_world program.
I installed the latest version of MinGW and trying to compile the project:
\MinGW\bin\gcc.exe -O3 -flto -Wall -msse src/*.c -o noname -lm -lpthread
But nothing happens. No errors, no exe files, nothing.
I am not familiar with Windows in terms of compilation.
This is a simple console application that is compilable on Ubuntu without problems with the same command.
What I am doing wrong?
I'm looking for a GNU toolchain:
target platform is aarch64 bare metal (cortex-a53/armv8-a)
host Mac OSX
Or by other words I need a bunch of aarch64-none-elf-* files
Any advise where could I get these tools?
Thanks
You don't need the -none- version of the toolchain anymore on aarch64. You can simply use aarch64-linux-gnu-gcc for instance, with the right parameters (no standard libs or headers):
aarch64-linux-gnu-gcc -march=armv8-a -nostdinc -fno-builtin -c -o main.o main.c
I am experimenting with cross compiling for ARM-Linux under Windows using Eclipse-Mars. My set-up is as follows:
Win10 x64
Eclipse Mars.2 Release (4.5.2)
GNU Toolchain for RaspberryPi (SysGCC)
Target platform: RaspberryPi2 running Raspian
Source project in 'C (not C++) using Linux Threads (pthreads)
I have knocked up a small 'C project using 'pthreads' which compiles under Eclipse and runs successfully on the Pi.
My problem is that Eclipse shows a number of errors in its Problems TAB to do with Linux's threads:
Type 'pthread_cond_t' could not be resolved
Type 'pthread_mutex_t' could not be resolved
Type 'pthread_t' could not be resolved
I have Eclipse as:
Cross GCC Compiler settings to use g++ with -std=c++11 -O0 -g3 -Wall -c -fmessage-length=0.
Cross G++ Compiler settings to use g++ with -std=c++11 -O0 -g3 -Wall -c -fmessage-length=0.
In other words both are the same.
If I rename my source files from foo.c to foo.cpp and recompile, then the Eclipse errors disappear!!!
This implies that Eclipse's C++ settings are correct, but its 'C settings are not.
Can anybody suggest anything for me to try?
g++ ist a C++ compiler, so you might try to use other settings for the Cross GCC Compiler, eg. gcc.
Also make sure you are linking the pthread library.
Following the instructions given here, I’ve downloaded the latest version of OpenSSL (openssl-1.0.1e.tar.gz) from here and installed it on Ubuntu v12.10 (32-bit).
I have a C project in Eclipse CDT (v1.2.0.201212170456) that statically links to the following two .a files:
home/usr/local/ssl/lib/libcrypto.a
home/usr/local/ssl/lib/ libssl.a
However when I build my project I get these errors:
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /usr/local/ssl/lib/libssl.a when searching for -lssl
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find –lssl
My toolchain is CodeSourcery (Sourcery G++ Lite 2010q1-202) and is for 32-bit OS.
What am I doing wrong?
Compiler command line I'm using:
arm-none-linux-gnueabi-gcc -I"/path to my/include" -O0 -g3 -Wall -c -fmessage-length=0 -v -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
You have installed OpenSSL on an Ubuntu 32-bit machine (assuming x86), but are trying to link it to an ARM binary:
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi: your ARM toolchain
/usr/local/ssl/lib/libssl.a: a 32-bit x86 version of OpenSSL
You will have to cross-compile OpenSSL for ARM using your ARM toolchain (i.e.: arm-none-linux-gnueabi-gcc), then you will be able to link it to an ARM binary.
It says that /usr/local/ssl/lib/libssl.a is not in the size expected. Try file on it to check if you compiled it in 32 or 64 bit version. And check how you are compiling your own program too. If both matches linker (ld) will link it fine.
If you compile your program into 64 bit and link it with libssl.a in 32 bit, this will not work
example:
file a.out
/* kind ofoutput */ a.out: Mach-O 64-bit executable x86_64
http://unixhelp.ed.ac.uk/CGI/man-cgi?file