I'm trying to compile the "stress-ng" package to produce a statically linked executable to use it inside GEM5 full system simulator.
A tarball of this package can be downloaded here. The version I'm trying to compile is 0.07.08.
To compile a dynamically linked executable of this package, just "make". This works for me.
However, since I need to run the "stress-ng" exe from within a GEM5 full system simulation, I need to make sure that the exe is self-contained. This is usually done using the "-static" CFLAG option, however, for "stress-ng", I get an error when I try this option.
Here is what to do in order to reproduce this error. Edit "Makefile" and add "-static" option at the end of line # 25. Line 25 should look like the following:
CFLAGS += -Wall -Wextra -DVERSION='"$(VERSION)"' -O2 -std=gnu99 -static
Save then make, you will see the error below:
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libpthread.a(lowlevellock.o): In function `__lll_lock_wait_private':
/build/eglibc-3GlaMS/eglibc-2.19/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:78: multiple definition of `__lll_lock_wait_private'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x0): first defined here
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libpthread.a(lowlevellock.o): In function `__lll_unlock_wake_private':
/build/eglibc-3GlaMS/eglibc-2.19/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:328: multiple definition of `__lll_unlock_wake_private'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x30): first defined here
collect2: ld returned 1 exit status
make: *** [stress-ng] Error 1
Finally, OS is Ubuntu 14.04 and cc version is 4.6.4.
Am I missing some other CFLAG option(s) here?
I've pushed a new fix to the stress-ng repo that now allows static linking. The issue was that -lc was before -lpthread, which caused the problem.
Pull the latest changes and then build with:
STATIC=1 make
Related
Based on This Stackoverflow link I downloaded & installed glibc v2.29 in "/usr/local/glibc" path of Linux OS. Then based on this Stackoverflow link I tried to compile This Example, But I got following errors.
First Try Command:
gcc -Wall -g -o main main.c -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
First Try Error Log:
main.c:1:10: fatal error: threads.h: No such file or directory
#include <threads.h>
^~~~~~~~~~~
compilation terminated.
Second Try Command:
In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
Second Try Error Log:
/tmp/ccCNYemW.o: In function `main':
/home/.../main.c:14: undefined reference to `thrd_create'
/home/.../main.c:16: undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
So I don't know where is the problem. Please Help me.
First of all, don't put an alternate libc (or alternate version of your libc) in a path searched by the normal include and library search (both link-time and runtime library search) for your main system one. This is a recipe for disaster. Installing a different glibc in /usr/local/ does avoid clobbering your system one, but now you just have two installed in places where the same tools can see and use them.
To do this right, you really need a full separate toolchain (gcc, binutils) in some completely separate path (like ~/my_glibc_root/... or /opt/alt_glibc_root/...). I'm not sure if there's a recommended way to do this. The glibc build procedures in Linux From Scratch might be a good place to look for ideas. In theory it can be done in a single stage; I do that with musl libc in musl-cross-make by careful use of intermediate make rules in the gcc build system. But applying the same idea to glibc probably requires some extra care.
Second Try Command: In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
This command is almost correct. The thrd_create and thrd_join functions are defined in libpthread, which you didn't link against.
Add -pthread to your compile command, and the link should succeed.
P.S. R's advice of not installing alternate GLIBC into /usr/local is also a good one.
I am want to begin working on the 4th assginment, RSS searcher, of Online Stanford CS107 Programming Paradigms course. However, I am lagging at the very first step; I can not compile the prepared, to-work-on, unfinished program.
I get this error when I type make;
gcc rss-news-search.o -g -Wall -std=gnu99 -Wno-unused-function -g -lnsl -lrssnews -L/media/D/Programming/assn-4-rss-news-search-lib/ -o rss-news-search
/usr/bin/ld: cannot find -lrssnews
collect2: error: ld returned 1 exit status
Makefile:32: recipe for target 'rss-news-search' failed
make: *** [rss-news-search] Error 1
I have installed libexpat-dev.
Here is the link to the course, its the 4th programming assignment, RSS;
https://see.stanford.edu/Course/CS107
Thanks in advance
That the project comes with librssnews.a is good news. This file is a static library called rssnews and this is what you need to compile the project successfully!
Warning: you almost certainly don't need to follow these steps, go on reading to see why.
Put this file in your project's directory (the one you're running the build from) or in the lib directory, if the project contains one (if it doesn't, don't create one).
Run the build again. If it fails with the same error, go on to next steps.
Find out where the compiler normally looks for libraries by compiling a simple code with the -v flag. For example, gcc simple.c -v. You'll get tons of output that will contain the paths the compiler visited to link your program.
Copy the library file to one of these paths and run the build once again.
Given that the library search path is specified explicitly, you can simply put the library into /media/D/Programming/assn-4-rss-news-search-lib/ and skip the steps discussed earlier altogether. But if it wasn't, you'd probably have to follow them.
I'm trying to execute the below program-
Within APUE.3E -> filedir -> filetype.c (this comes by default when I downloaded APUE.3E. I didn't make any changes)
but when I compile this is the error I'm receiving:
myramya~/Documents/apue.3e/filedir$ gcc filetype.c -lm -o filetype
/tmp/cchPKE7K.o: In function main':
filetype.c:(.text+0x94): undefined reference to err_ret'
collect2: error: ld returned 1 exit status
I'm using Linux Ubuntu. I have installed APUE.3E in Documents folder. I have administrator permissions. I wrote a simple Hello.c program and executed using:
$ gcc hello.c -o hello
and it worked without any issues.
Your hello example works compiling in a single step with gcc because it does not call any functions in other files (except functions in the standard C library which allways gets linked in).
Your filetype.c makes calls to a function err_ret which is not within filetype.c but in some other source file.
When compiling bigger programs the work is usually done in two steps: First source files are compiled into object files by making one call to gcc with the flag -c for each source file. Then all object files are linked together with a single call to gcc with all object files. It is also possible to put object files together into libraries. Usually a Makefile is used to compile bigger projects.
Your specific case with apue.3e is well explained here: https://unix.stackexchange.com/questions/105483/compiling-code-from-apue
I'm using cmake to generate a gstreamer library. In the end cmake uses the following command for linking:
/usr/bin/cc -fPIC -shared -Wl,-soname,libmacq-gstmelpi.so -o libmacq-gstmelpi.so <OBJECT_FILES> -lmacq-melpi -lmacq-icar-tools -lmacq-gstmecimeta -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstvideo-1.0
Note the -lgstvideo-1.0 flag at the end. The command runs fine, no error is produced, and the resulting library is created just fine. However when I use the library, I get undefined symbol error. So I use ldd to check; and amongst all the output of ldd; libgstvideo-1.0.so is not to be found.
This problem occurs on Ubuntu 14.04 on a armhf architecture. The problem does not occur on opensuse 13.1 (i586) nor on opensuse 13.1 (armv7hl), since in that case ldd libmacq-gstmelpi.so | grep gstvideo gives:
libgstvideo-1.0.so.0 => /usr/lib/libgstvideo-1.0.so.0 (0xb715f000)
EDIT :
I have another library, very similar where a very similar command works just fine; the resulting library is correctly linked to libgstvideo-1.0.so
/usr/bin/cc -fPIC -shared -Wl,-soname,libmacq-gstplugins.so -o libmacq-gstplugins.so <OBJECT_FILES> -lmacq-icar-tools -lmacq-gstmecimeta -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstvideo-1.0
Some remarks on what I have checked and tried:
/usr/lib/arm-linux-gnueabihf/libgstvideo-1.0.so exists. (the other libraries in /usr/lib/arm-linux-gnueabihf/ are found without problem, libmacq-gstmelpi.so is linked to /usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0 without problem)
I tried changing the order, and putting the -lgstvideo-1.0 flag before all other -l flags; no succes.
replacing cc with c++ or gcc; the commands work, but output is the same
removing -lgstvideo-1.0 on a system where the build worked. The resulting library builds (links) without error; yet upon execution I have the same undefined symbol error as on Ubuntu. This proves that the missing symbol is in libgstvideo-1.0.so, and that I need it.
Are you actually using symbols from that particular library or do you just want to link to it to avoid linking it in the application that uses the library later on?
It could be a default compiler behavior that it skips linking of libraries when no symbol from these are actually used.
Try -Wl,--no-as-needed to your flags. In this case the library should get linked - not checking whether its symbols are actually used or not.
EDIT:
After chatting it turned out that the actual desired symbols are in gstbase-1.0 and not gstvideo-1.0. Since gstvideo-1.0 pulls in gstbase-1.0 as a dependency this worked but would cause problem as the linker may remove this dependency since no symbols from this particular library are being used. Linking directly to gstbase-1.0 seemed to solve all issues.
I'm trying to write a very small, very simple project using PJSIP. But I'm already stuck on the first step, incorporating PJSIP in my project. I'm trying to build and compile on a Ubuntu 14.04 system using an arm-linux-gnueabihf-gcc cross compiler. For the coding itself I'm using Eclipse CDT, but the crosscompiling part is working in a normal order.
I downloaded de pjproject-2.3 folder to my system, configured it with this command:
./configure --host=arm-linux-gnueabihf CFLAGS='--sysroot=/home/david/rpi/rootfs' LDFLAGS='--sysroot=/home/david/rpi/rootfs'
The /home/david/rpi/rootfs folder is where I copied the rootsystem of my Pi. I then ran 'make dep' and 'make'. I copied all the static libraries *.a to my Eclipse project folder and added the libraries to the linker (-l).
But when I want to build I get the following error:
Invoking: Cross G++ Linker
arm-linux-gnueabihf-g++ -L"/home/david/workspace/VoIPBenchmark" -L/home/david/rpi/rootfs/usr/lib -L/home/david/rpi/rootfs/usr/lib/arm-linux-gnueabihf --sysroot=/home/david/rpi/rootfs/ -o "VoIPBenchmark" ./src/SipImplemantation.o ./src/SipImplementationPJ.o ./src/Timer.o ./main.o -lpjsua2-arm-unknown-linux-gnueabihf -lpjsua-arm-unknown-linux-gnueabihf -lpjsip-ua-arm-unknown-linux-gnueabihf -lpjsip-simple-arm-unknown-linux-gnueabihf -lpjsip-arm-unknown-linux-gnueabihf -lpjsdp-arm-unknown-linux-gnueabihf -lpjmedia-audiodev-arm-unknown-linux-gnueabihf -lportaudio-arm-unknown-linux-gnueabihf -lpjmedia-codec-arm-unknown-linux-gnueabihf -lpjmedia-arm-unknown-linux-gnueabihf -lspeex-arm-unknown-linux-gnueabihf -lgsmcodec-arm-unknown-linux-gnueabihf -lsrtp-arm-unknown-linux-gnueabihf -lilbccodec-arm-unknown-linux-gnueabihf -lresample-arm-unknown-linux-gnueabihf -lpjnath-arm-unknown-linux-gnueabihf -lpjlib-util-arm-unknown-linux-gnueabihf -lpj-arm-unknown-linux-gnueabihf -lpthread -lm -lrt -lasound -llinphone
/home/david/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: /home/david/workspace/VoIPBenchmark/libsrtp-arm-unknown-linux-gnueabihf.a(ctr_prng.o)(.text+0x8c): unresolvable R_ARM_ABS32 relocation against symbol `ctr_prng'
/home/david/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [VoIPBenchmark] Error 1
I googled some and tried to add -fPIC in the ./configure step above, recopied the libraries, but without result. Does anyone know what this message is saying me, and better yet, knows a solution?
This problem has been resolved. I was using a library that also linked to the srtp library, this evidently conflicted. So I am now not using the library that causes the problem.