I use gcc on Solaris 10 to build make program, and get the following information:
gcc: unrecognized option `-rdynamic'
After checking the rdynamic in gcc document, I get the following explantions:
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.
My questions are:
(1) Although gcc prints "gcc: unrecognized option -rdynamic", the build is still success. Is this the default behavior of gcc?
(2) I replace "-rdynamic" with "-export-dynamic" in Makefile, and the build is success. Is there any side-effect of this substitution?
P.S. My gcc information:
bash-3.00# gcc -v
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6
You are using an obsolete version of gcc, but you refer to an up-to-date documentation. There is no such linker option for gcc-3.4.6, see https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Link-Options.html.
Try using -Wl,--export-dynamic option when linking instead.
I replace -rdynamic with -export-dynamic in Makefile, and the build is success. Is there any side-effect of this substitution.
This option is not documented, it may well do nothing, you need to check strace output what command line options it passes to the linker.
Related
I have successfully built clang and lld from source, and both are now available under my .../llvm-project/build/bin directory.
Following lld documentation, I am now trying to pass -fuse-ld=lld command line directive to clang to force it to use lld instead of system's default linker (which is GNU ld if I am not mistaken) as follows:
../llvm-project/build/bin/clang -fuse-ld=lld -c test.c
But I get this warning:
clang-16: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
Which I suppose means lld was not used as the linker despite me asking for it.
What am I doing wrong?
I am on Ubuntu 22.04.1 LTS x86_64 and I am using clang version 16.0.0 and lld 16.0.0.
What am I doing wrong?
This: clang -fuse-ld=lld -c test.c is a compilation command. It does not perform any linking.
This argument: -fuse-ld=lld is telling the compiler driver which linker to use at link time.
You told the driver:
to not do linking (the -c argument) and
to use lld for linking in the same command
The driver has no choice but to ignore your second instruction, since it's not going to do any linking, and that's what the warning is all about.
You can safely ignore this warning, but a better solution is to pass the -fuse-ld=lld argument only to the link stage, and not to any compile stages.
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 not sure if the question is framed correctly. But I am using code blocks on a windows machine. I want to use gcc -o myfile myfile.c -lpthread. But in my code blocks I don't have this -lpthread flag(is that called a flag?). So where do I need to add this in code blocks so that when I click build, it will simply call gcc -o myfile myfile.c -lpthread.
-lpthread is a flag to the linker saying to include the library pthread (POSIX threads). I'm not particularly good with code blocks but in the main settings you should be able to find options for configuring the compiler or linker. You need to add the library "pthread" there.
Take a look at this possible duplicate: How do I link to a library with Code::Blocks?
In codeblocks 16.01, you can specify the library you want to link (in this case libpthread.so) via Settings > Compiler... > Linker Settings > Add
Then you need to add the location of libpthread.so via locate libpthread.so
In this case, you may also need to specify -D_REENTRANT compiler flag to tell gcc about necessary headers for thread usage.
My LIBRARY_PATH variable is exported, but I still have to pass the -L option to gcc in order to link to my library.
If I understand the GCC documentation correctly 3.20 Environment Variables Affecting GCC, the LIBRARY_PATH environment variable should be looked so that I only have to specify the -l option.
When I run
gcc -Wall cog.c -L$HOME/lib -lutil
the program is compiled, and I get an a.out as expected.
If I run
gcc -Wall cog.c -lutil
I get an undefined reference error.
As far as I can tell, I've properly exported the environment variable.
cassiopeia~> export LIBRARY_PATH=$HOME/lib
cassiopeia~> ls $LIBRARY_PATH
libutil.a
Any clues?
For what it's worth, I'm using Fedora 23 64bit and gcc version 5.3.1 20160406 (Red Hat 5.3.1-6).
Your distro probably is multilib-enabled. If this is the case, all path strings to libraries are expanded with the architecture for this machine (typically 32-bit or 64-bit). So, if you specify
$HOME/lib
as your search path, multilib might expand it to
$HOME/lib/x86_64-linux/4.6
or
$HOME/lib/x86_32-linux/4.6
You can check if this is the case by invoking gcc once using
gcc --print-search-dirs
This makes gcc respond with all search paths in use for config and libraries.
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.