I am not familiar with OS X at all, and I need to compile a C file. Here is the code I use in Linux. What is the OS X version of those?
gcc -m64 -std=gnu99 -I/usr/include/R -DNDEBUG -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c myfile.c -o myfile.o
gcc -m64 -std=gnu99 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o myfile.so myfile.o -L/usr/lib64/R/lib -lR
Thanks!
You need to install Xcode, which is free, and will allow you to install gcc just by typing gcc in Terminal. From there on, you can just compile .c files using it. Also, you might want to just type gcc myfile.c -o myfile instead of adding all of those flags, because the OS X filesystem hiearchy is different from that of Linux, and adding those extra flags might make the command not work.
Related
I am new to Makefile, C and Linux. I am using gcc & ubuntu. I encountered a problem while trying to compile the code with a link to a library.
Here is my problem. I have:
a_tests.c & b_tests.c files in "tests" folder
lib.a file in "build" folder
Here is the codes in Makefile related to the problem:
CFLAGS=-g -O2 -Wall -Wextra -Isrc -DNDEBUG $(OPTFLAGS)
TARGET=build/lib.a
TEST_SRC=$(wildcard tests/*_tests.c)
TESTS=$(patsubst %.c,%,$(TEST_SRC))
tests: CFLAGS += $(TARGET)
tests: $(TESTS)
When the tests files are compiled, "undefined reference to 'XXXfunction'"errors will be prompted. Because what executed behind is
gcc -g -O2 -Wall -Wextra -Isrc -DNDEBUG build/lib.a tests/a_tests.c -o test/a_tests
gcc -g -O2 -Wall -Wextra -Isrc -DNDEBUG build/lib.a tests/b_tests.c -o test/b_tests
But "build/lib.a" should be placed after the output file name to solve it (If I manually type in the below commands, the codes would be successfully compiled), ie:
gcc -g -O2 -Wall -Wextra -Isrc -DNDEBUG tests/a_tests.c -o test/a_tests build/lib.a
gcc -g -O2 -Wall -Wextra -Isrc -DNDEBUG tests/b_tests.c -o test/b_tests build/lib.a
But I don't know how to change in the Makefile, I tried -l -L options, they didn't work. It would warn that "cannot find the .a file". Any help would be appreciated. Thank you so much in advance!
Define the library as a dependency, because it is one. It will be appended at the end of the other dependencies, here: the source.
CFLAGS=-g -O2 -Wall -Wextra -Isrc -DNDEBUG $(OPTFLAGS)
TARGET=build/lib.a
TEST_SRC=$(wildcard tests/*_tests.c)
TESTS=$(TEST_SRC:%.c=%)
tests: $(TESTS)
$(TESTS): $(TARGET)
The library does not need to be after the output file, but after the depending input file.
The makefile is further simplified:
Replaced the patsubst with a simpler expression.
Moved the target tests up, so it is found as the first and therefore default target.
Good luck!
I try to build PDCurses using MinGW, but have a problem in the second file which is specific for win32a:
..PDCurses-master\win32a>mingw32-make -f mingwin32.mak WIDE=Y UTF8=Y
...
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../pdcurses/window.c
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../pdcurses/debug.c
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../win32a/pdcclip.c
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../win32a/pdcdisp.c
../win32a/pdcdisp.c:451:1: error: unknown type name 'GLYPHSET'
GLYPHSET *PDC_unicode_range_data = NULL;
^
And some other errors in lines 450 - 470.
I have already reinstall MinGW, but the problem is the same. What am i doing wrong?
I'm compiling a library that comes with a scons script. According to the documentation scons does everything automatically and stuff should just work.
However, the build succeeds or fails, depending on what I set CC to (even though I always invoke the same compiler):
/usr/bin/ld: context.os: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
context.os was built with the following arguments.
env cc -o context.os -c ... -Wall -O2 -DNDEBUG -I. -I/usr/local/include ... context.c
So scons forgets the -fPIC argument. However if I set CC=cc it succeeds:
cc -o context.os -c ... -Wall -O2 -fPIC -DNDEBUG ...
The same if I set CC="ccache cc":
ccache cc -o context.os -c ... -Wall -O2 -fPIC -DNDEBUG ...
And of course, with -fPIC set, linking succeeds in both cases.
So, I wonder how does scons position independent code trigger work and why does it screw up in the CC="env cc" case?
consider c.c a code that includes a.h and b.h, and main.c a code that includes c.h
i tried to compile it like so
gcc --std=c99 -o a.o -c a.c
gcc --std=c99 -o b.o -c b.c
gcc --std=c99 -o c.o -c c.c a.o b.o
but when I run the last one, gcc yells at me
gcc --std=c99 -o c.o -c c.c a.o b.o
gcc: warning: a.o: linker input file unused because linking not done
gcc: warning: b.o: linker input file unused because linking not done
and then when I try to compile the main.c file using gcc -o main main.c c.o it says that there are a lot of undefined references, which is predictable once the c file was not correctly compiled.
I've seen some similar questions here at stackoverflow, but I couldn't get it to work neither way.
I'm on Arch Linux running gcc v4.9.2-3
First, it is -std=c99 with a single dash.
I guess you are on Linux.
Then, you always should pass -Wall -Wextra -g (especially since you are a newbie) to gcc : -Wall ask for nearly all warnings, -Wextra for even more warnings, -g ask for debug information.
At last, you want to produce an executable myprog (don't name executables as c.o, this is supposed to be an object file) with
gcc -std=c99 -Wall -Wextra -g -o myprog c.c a.o b.o
You need to remove any -c since you want the linking to happen.
If you really mean -but that is very unusual today, better make shared libraries!- to agglomerate several object files into one all.o (to be linked later with other objects) you might try the -r linker option
gcc -std=c99 -Wall -Wextra -g -r c.c a.o b.o -o all.o
But last time I tried it was in the previous century, so details could be wrong.
There are very few reasons to agglomerate objects using the -r linker option. Unless you really know what you are doing, you are very probably wrong (in trying -r).
Perhaps you want to make a software library. These days it is much better to make a shared library. A shared library (technically an ELF shared object) should contain position independent code. So, assuming you have three translation units t1.c, t2.c, t3.c you first compile them as PIC :
gcc -std=c99 -Wall -Wextra -g -fPIC t1.c -c -o t1.pic.o
gcc -std=c99 -Wall -Wextra -g -fPIC t2.c -c -o t2.pic.o
gcc -std=c99 -Wall -Wextra -g -fPIC t3.c -c -o t3.pic.o
then you link all these PIC object files into a shared library libmyt.so
gcc -std=c99 -Wall -Wextra -g -shared \
t1.pic.o t2.pic.o t3.pic.o \
-o libmyt.so
Later you'll use this shared library e.g. as
gcc -std=c99 -Wall -Wextra -g main.o -o myprog -Wl,-rpath . libmyt.so
or as
gcc -std=c99 -Wall -Wextra -g main.o -o myprog -Wl,-rpath . -L. -lmyt
You might consider static linking with ar to make a static library libmyt.a but I don't recommend that.
Of course, you'll debug your program using gdb ./myprog and you could try running it with ./myprog. To use valgrind, try valgrind ./myprog
If you have several translation units, better learn how to use GNU make. Read the Program Library HowTo and this and these hints.
I need to build a wget incomplete executable using gcc for RHEL4 that will use a specific OpenSSL shared lib. LD_LIBRARY_PATH is unset at build time.
This is quite simple by specifying:
LDFLAGS="-W1,-rpath=/usr/local/ssl/lib -L/my_build_dir/usr/local/ssl/lib"
and all is good.
But this makes the RPATH in the dynamic section of my incomplete executable:
Library rpath: [/usr/local/ssl/lib:/my_build_dir/usr/local/ssl/lib]
Is it possible using the gcc toolchain to set the RPATH to only use what is specified using the -rpath option and to ignore all library paths declared at build time?
I have looked at many SO posts today incl.:
I don't understand -Wl,-rpath -Wl, , and
What's the difference between -rpath and -L?
but nothing seems to address the issue of removing build info from the final incomplete executable.
EDIT: Here is the full command line for the final link phase.
gcc -Wall -std=c99 -m32 -march=athlon -mfpmath=sse -msse2 -O2 -pipe -s \
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -m32 -march=athlon \
-mfpmath=sse -msse2 -O2 -pipe -s -Wl,-rpath,/usr/local/ssl/lib \
-L/my_build_dir/usr/local/ssl/lib -o wget cmpt.o connect.o convert.o \
cookies.o ftp.o css_.o css-url.o ftp-basic.o ftp-ls.o hash.o host.o \
html-parse.o html-url.o http.o init.o log.o main.o netrc.o progress.o \
ptimer.o recur.o res.o retr.o spider.o url.o warc.o utils.o exits.o
build_info.o iri.o version.o ftp-opie.o openssl.o http-ntlm.o \
../lib/libgnu.a /my_build_dir/usr/local/ssl/lib/libssl.so \
/my_build_dir/usr/local/ssl/lib/libcrypto.so -Wl,-rpath \
-Wl,/my_build_dir/usr/local/ssl/lib -ldl -lz -lidn -luuid -lrt
Thanks to the comments of nos and keltar below I can see where the issue is.
Now to work out why configure finishes up specifying the two openssl libs with their fullpath.
EDIT 2: Just to confirm that that the -rpath and -L option are working correctly.
If I rewrite the above command to remove the hard references to the build location of the openssl libs then RPATH in the incomplete executable is set to just /usr/local/ssl/lib.
Full edited command is:
gcc -Wall -std=c99 -m32 -march=athlon -mfpmath=sse -msse2 -O2 -pipe -s \
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -m32 -march=athlon \
-mfpmath=sse -msse2 -O2 -pipe -s -Wl,-rpath,/usr/local/ssl/lib \
-L/my_build_dir/usr/local/ssl/lib -o wget cmpt.o connect.o convert.o \
cookies.o ftp.o css_.o css-url.o ftp-basic.o ftp-ls.o hash.o host.o \
html-parse.o html-url.o http.o init.o log.o main.o netrc.o progress.o \
ptimer.o recur.o res.o retr.o spider.o url.o warc.o utils.o exits.o \
build_info.o iri.o version.o ftp-opie.o openssl.o http-ntlm.o \
../lib/libgnu.a -lssl -lcrypto -ldl -lz -lidn -luuid -lrt