I got a gcc compilation error:
gcc-4.9: error: unrecognized command line option '-rdynamic'
and I tested compilation with -rdynamic in some environments. While I used the same version of gcc (4.9.2), in some environments gcc worked well, but others (e.g. Homebrew gcc 4.9.2_1, cygwin 64bit) not. What makes the difference?
-rdynamic passes the flag -export-dynamic to ELF linker, on targets that support it.
Executable formats in OS X and Windows are not ELF, thus the option -rdynamic is not supported building for these operating systems.
Related
I have a program written on Linux in GNU C. The program compiles with GCC. I have an install shell script,
gcc -o program program.c -Wall -pedantic -std=gnu11 -lm -fopenmp
which works greatly.
The problem is with Mac. For some reason, Mac sees gcc and instead uses clang even though GCC is installed and install.sh explicitly says gcc. clang doesn't work with omp.h The problem is that clang can't use omp.h and solutions offered http://releases.llvm.org/3.7.0/tools/clang/docs/ReleaseNotes.html#openmp-support don't work, and omp.h may not work in mac at all Enable OpenMP support in clang in Mac OS X (sierra)
I never use macs, and because of this nonsense I never plan to. However, some people using my program want to use Mac, so I have to deal with this.
I've tried various shell script modifications, but none of them work, mac insists on using clang and won't use gcc
I need to do one of two things which I don't know how to do:
1) force Mac to use gcc (which it refuses to do now)
2) get clang to use omp.h in mac (which from other answers on Stack Overflow, looks impossible)
Your second option (get clang to use omp.h) is not impossible (any more). From my answer here:
Try using Homebrew's llvm:
brew install llvm
You then have all the llvm binaries in /usr/local/opt/llvm/bin. To compile the OpenMP Hello World program, for example, type
/usr/local/opt/llvm/bin/clang -fopenmp -L/usr/local/opt/llvm/lib omp_hello.c -o hello
You might also have to set the CPPFLAGS with -I/usr/local/opt/llvm/include.
I've used linuxbrew to install gcc 5.3 on a machine on which I don't have sudo access. I now want to link with X11:
> gcc test.c -lX11
ld: cannot find -lX11
I've checked that libX11.so exists in /usr/lib64/ which is on the compiler's LIBRARY_PATH. If I use the system's gcc it works fine, but I need a newer version to compile my actual program.
use -L flag, like this -L/usr/lib64, or you can specify full path to library like this gcc test.c /usr/lib64/libX11.so
According to this comment by a linuxbrew developer,
linuxbrewed gcc removes /usr/lib64 from the library path because mixing system libraries with brewed libraries creates havoc.
The solution is to brew install linuxbrew/xorg/xorg.
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.
I am working on a program which uses ncurses which will be used on embedded systems. Since these systems won't have ncurses installed I need to statically link the library. However if I try to build it like this
gcc -static ncurs.c -o ncurs -l:libncurses.a
or
gcc -static ncurs.c -o ncurs -lncurses
I get a ton of errors like this:
(.text+0x48): undefined reference to `SP'
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libncurses.a(lib_slktouch.o): In function `slk_touch':
normal compilation works fine.
I have searched for hours but I can't find any good information...
platform of development is stripped down debian system.
I guess you may need additional library, can you try -lncurses -ltinfo.
You can check on your system what the linker library flags for ncurses using command
pkg-config --static --libs ncurses
on my system, I got
-lncurses -ltinfo
try adding -ltinfo to the end of your commandline
When I run the following command from a makefile on 64-bit Red Hat Enterprise Linux 5.0 using GCC 4.2.3:
gcc -c -ansi -pedantic -O0 -fPIC -I. -I.. -Iheader_files/include "source_file.c"
I get the following error:
cc1: error: unrecognized command line option "-lang-c"
Superficially, the problem is that "-lang-c" is no longer a valid option on newer versions of GCC. However, the deeper question is: Why does GCC receive a "-lang-c" option that wasn't in the original command?
Additional background:
The current installation doesn't have any GCC "specs" files that I can find
Running "gcc -dumpspecs" produces a long list of defaults, but "-lang-c" isn't among them.
"-lang-c" does not appear to be in any environment variables that I know of that influence GCC.
Any help would be appreciated.
Regards,
Mark Biesiada
Make sure that your gcc driver program is the same version as your installed GCC.
Add the -v option to your compile command to check the versions and where the options are coming from.