The project I'm currently working on uses a bunch of dynamic libs bundled together with the source code. There is a subset of libs which is named as follows:
for a given lib libABC, there are four files:
libABC.so
libABC.so.4
libABC.so.4.5
libABC.so.4.5.0
They are daisy-chained like this:
the first file, libABC.so, contains the following:
link libABC.so.4
whereas the next file, libABC.so.4, contains the following:
link libABC.so.4.5
and so on till the actual lib file, libABC.so.4.5.0.
I know that this kind of stuff should be done using symlinks, but we can't change that, it's a commercial project. So the linker chokes on that!
/usr/bin/ld: path/to/the/packaged/libs/libABC.so:unrecognized file format, treating as linker script
(which it actually is, heh)
/usr/bin/ld: path/to/the/packaged/libs/libABC.so:1:syntax error
Now I can't seem to find any info on the GNU ld linker script command "link" or any complete reference to the GNU ld linker script commands.
What could that be?
The linker script format is described in the GNU ld manual.
I found this issue myself today, and what happens is when you do a checkout using SVN on Windows (e.g. TortoiseSVN), the Linux symlink is converted into a text file.
Then, on the build process, ld is receiving a text file instead of a symlink that would lead to the concrete file.
Solution: svn checkout on the Linux machine.
Related
A cleaned up version of my compile command looks like gcc -o semantic_seg -Wl,-rpath,... -l:libnvrtc-5e8a26c9.so.10.1 ... and I have a dynamic library file named exactly libnvrtc-5e8a26c9.so.10.1 in the directory specified by the -rpath flag. The command succeeds.
When I go to run my program, it says semantic_seg: error while loading shared libraries: libnvrtc.so.10.1: cannot open shared object file: No such file or directory and when I do ldd it shows libnvrtc.so.10.1 => not found.
So the problem looks like the name of the shared library in the executable is not the same as the filename. Could that be true? Did the 5e8a26c9 part of the name somehow get stripped off?
Update: Creating a symbolic link libnvrtc-5e8a26c9.so.10.1 -> libnvrtc.so.10.1 allows the executable to run. But I'm still not sure the mechanism that causes this name modification to happen. It seems a bit magic.
Could that be true?
This is often true.
On ELF systems, the linker uses SONAME of the library (if it has one) and not its filename to record a runtime dependency.
Running readelf -d libnvrtc-5e8a26c9.so.10.1 | grep SONAME will likely show that in fact that library does have SONAME, and the value of SONAME is libnvrtc.so.10.1.
This used to be very convenient for external library versioning.
Update:
it allows you to link against a library which will be different than the one which will used at run time, but why would I ever want that?
Like I said, it's useful for external library versioning and ABI evolution.
Suppose you ship version 1.0 of libfoo.so. You provide libfoo.so as a symlink to libfoo.so.1, and you use libfoo.so.1 as SONAME.
Any program that links with gcc main.c -lfoo (note: no funny -l:libfoo.so.1 syntax required) will record libfoo.so.1 as its external dependency, and will use that name at runtime.
Time passes, and you are ready to ship version 2, which is not ABI-compatible.
You don't want to cause all your end-users to change their link line, and you don't want to break any existing binaries.
With the SONAME, this is trivial: new package will include libfoo.so.2 with SONAME of libfoo.so.2, and a symlink libfoo.so now pointing to libfoo.so.2.
Voila: both requirements are achieved: existing binaries continue to use libfoo.so.1, newly-linked binaries use libfoo.so.2, no Makefile changes required.
gcc -L/root/Desktop - Wall -o prog3.c -pthread -lcopy
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.0: In function '_start': (.text+0x20): undefined reference to 'main'
collect2: error: ld returned 1 exit status
This is my error code. prog3.c is nowhere to be found, what on earth happened is there any way to get my file back?? The bold is the command I ran and the rest is the resultant console output
Your problem is here: -o prog3.c. gcc’s -o option is used to tell gcc which name it should give to the executable it generates. So here, you’re basically asking your compiler to replace your prog3.c source file by an executable. Sadly your code is gone...
Little addendum of your options in such scenario:
It was Git (or any other version control) repository. In such case, you can simply bring it from previous commit
Your editor/IDE has some back-up system. Sometimes I need to bring back a file I've thought was needless. For such case, my favourite text editor should have create already back-up file in appropriate location (e.g. $XDG_DATA_HOME/vim/backup in my case).
If none of above, but you still have previously correctly compiled binary file
You can try to decompile, but this process - even if successful - isn't lossless (e.g. code is basically spaghetti).
Had you compiled with -g flag, you could possibly retrieve the code from debug info.
You can at least de-assemble to Assembly code.
I have the following warning during link:
/usr/bin/ld: warning: libxxx.so.6, needed by /a/b/c/libyyy.so, not found (try using -rpath or -rpath-link)
Setting environment variable LD_LIBRARY_PATH=path_to_libxxx.so.6 silence the warning (adding -Lpath_to_libxxx.so.6 doesn't help).
I have a separate compilation server, where the resulting binary is only compile.
The binary is executed on other server and there the libxxx.so.6 is seen by the binary (checked with ldd executable).
Is there're other way to get rid of the warning at compilation time (I have it several times and it's very annoying)?
You need to add the dynamic library equivalent of -L:
-Wl,-rpath-link,/path/to/lib
This will cause the linker to look for shared libraries in non-standard places, but only for the purpose of verifying the link is correct.
If you want the program to find the library at that location at run-time, then there's a similar option to do that:
-Wl,-rpath,/path/to/lib
But, if your program runs fine without this then you don't need it.
Make sure the paths to the needed libraries are known to the runtime linker. This is done by adding a file in /etc/ld.so.conf.d/ with the needed path. For example, /etc/ld.so.conf.d/foo with the following contents:
/usr/local/lib/foo/
If you have a very old Linux version, /etc/ld.so.conf.d/ might not be supported, in which case you might have to add the paths directly into the /etc/ld.so.conf file.
After you've done that, you need to update the linker's database by executing the "ldconfig" command.
I know this is old, but here's a better fix:
The root cause:
The problem actually happens when LD invoked by GCC starts resolving
library dependencies. Both GCC and LD are aware of the sysroot
containing libraries, however LD may be missing one critical
component: the /etc/ld.so.conf file. Here’s an exampleld.so.conf file
from a Raspberry PI system:
include /etc/ld.so.conf.d/*.conf
The /etc/ld.so.conf.d directory contains the following files:
00-vmcs.conf:
/opt/vc/lib
arm-linux-gnueabihf.conf:
/lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf
libc.conf:
/usr/local/lib
The universal solution
The problem can be easily solved by copying the LD configuration files
to a location where the cross-toolchain’s LD can find them. There’s
one pitfall however: if your cross-toolchain was built with MinGW
(most are), it probably did not have access to the glob() function so
it won’t be able to parse a wildcard-enabled include statement
like *.conf. The workaround here is to just manually combine the
contents of all .conf files from /etc/ld.so.conf.d and paste them
into /etc/ld.so.conf
*/opt/vc/lib
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
/usr/local/lib*
Once you create the ld.so.conf file in the correct folder, your
toolchain will be able to resolve all shared library references
automatically and you won’t see that error message again!
The only way to silence these warning using command line options would be the -L flag which curiously does not work for you (maybe you can post more details on this). Since the warning is generated by ld we could try to use -Wl,option to disable a linker warning but from the documentation of GNU ld however there is no option for (de)activating this warnings.
So this leaves us with writing a wrapper script filtering out this warning or compile a custom version of ld.
Everybody out there,
I'm writing a c code which have a strange problem when I compile it .
The source code is OK.
I compile it with following option:
$ gcc above_sample.c -I/home/hadoop/project/hadoop-0.20.2/src/c++/libhdfs -L/home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib -lhdfs -o above_sample.
But it show the out put like that:
/usr/bin/ld: warning: libjvm.so, needed by /home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib/libhdfs.so, not found (try using -rpath or -rpath-link) /home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib/libhdfs.so: undefined reference to `JNI_CreateJavaVM#SUNWprivate_1.1'
/home/hadoop/project/hadoop-0.20.2/c++/Linux-amd64-64/lib/libhdfs.so: undefined reference to `JNI_GetCreatedJavaVMs#SUNWprivate_1.1'
collect2: ld returned 1 exit status
I searched for libjvm.so i found It in my system in /usr/java/lib.
I made a symbolic link of it but did not work.
i copied the library in to several places like usr/lib check the LD_library_Path
but could not manage to compile the program it showing the same error again and again
Can any one tell me what I'm doing wrong ?
how to link .so file to gcc ?
or how .so files are linked in program?
Try adding:
-L/usr/java/lib
To your linker command, since that's the library your linker is not being able to find: I_GetCreatedJavaVMs#SUNWprivate_1.1.
A little piece of advice: it's not a good idea to mess with LD_LIBRARY_PATH. Just fix your linker command.
Linker gives a warning about not found reference to function JNI_CreateJavaVM#SUNWprivate_1.1
/usr/bin/ld: warning: libhdfs.so: undefined reference to
`JNI_CreateJavaVM#SUNWprivate_1.1'
This function name might be specific for library from Sun/Oracle HotSpot JVM. Other JVMs may have another name. For example, mine OpenJDK had only shorter name such as JNI_CreateJavaVM and linker gave me the same warning.
You may get list of the functions from your libjvm.so by running command:
readelf -s libjvm.so | grep JNI_CreateJavaVM # given that you are in catalog containing libjvm.so
If output does not contain required function, then you might want to install another JDK.
That's what worked for me:
CDH=/opt/cloudera/parcels/CDH
OS_ARCH=amd64
gcc hdfs_example.c -I$CDH/include -L$CDH/lib64 \
-L/usr/java/default/jre/lib/${OS_ARCH}/server \
-ljvm -lhdfs -o hdfs_write_test
How can I link a shared library function statically in gcc?
Refer to:
http://www.linuxquestions.org/questions/linux-newbie-8/forcing-static-linking-of-shared-libraries-696714/
You need the static version of the library to link it.
A shared library is actually an executable in a special format
with entry points specified (and some sticky addressing issues
included). It does not have all the information needed to
link statically.
You can't statically link a shared library (or dynamically link a static one).
The flag -static will force the linker to use static libraries (.a) instead of shared (.so) ones. But static libraries aren't always installed by default, so you may have to install the static library yourself.
Another possible approach is to use statifier or Ermine. Both tools take as input a dynamically linked executable and as output create a self-contained executable with all shared libraries embedded.
If you want to link, say, libapplejuice statically, but not, say, liborangejuice, you can link like this:
gcc object1.o object2.o -Wl,-Bstatic -lapplejuice -Wl,-Bdynamic -lorangejuice -o binary
There's a caveat -- if liborangejuice uses libapplejuice, then libapplejuice will be dynamically linked too.
You'll have to link liborangejuice statically alongside with libapplejuice to get libapplejuice static.
And don't forget to keep -Wl,-Bdynamic else you'll end up linking everything static, including libc (which isn't a good thing to do).
Yeah, I know this is an 8 year-old question, but I was told that it was possible to statically link against a shared-object library and this was literally the top hit when I searched for more information about it.
To actually demonstrate that statically linking a shared-object library is not possible with ld (gcc's linker) -- as opposed to just a bunch of people insisting that it's not possible -- use the following gcc command:
gcc -o executablename objectname.o -Wl,-Bstatic -l:libnamespec.so
(Of course you'll have to compile objectname.o from sourcename.c, and you should probably make up your own shared-object library as well. If you do, use -Wl,--library-path,. so that ld can find your library in the local directory.)
The actual error you receive is:
/usr/bin/ld: attempted static link of dynamic object `libnamespec.so'
collect2: error: ld returned 1 exit status
Hope that helps.
If you have the .a file of your shared library (.so) you can simply include it with its full path as if it was an object file, like this:
This generates main.o by just compiling:
gcc -c main.c
This links that object file with the corresponding static library and creates the executable (named "main"):
gcc main.o mylibrary.a -o main
Or in a single command:
gcc main.c mylibrary.a -o main
It could also be an absolute or relative path:
gcc main.c /usr/local/mylibs/mylibrary.a -o main
A bit late but ... I found a link that I saved a couple of years ago and I thought it might be useful for you guys:
CDE: Automatically create portable Linux applications
http://www.pgbovine.net/cde.html
Just download the program
Execute the binary passing as a argument the name of the binary you want make portable, for example: nmap
./cde_2011-08-15_64bit nmap
The program will read all of libs linked to nmap and its dependencias and it will save all of them in a folder called cde-package/ (in the same directory that you are).
Finally, you can compress the folder and deploy the portable binary in whatever system.
Remember, to launch the portable program you have to exec the binary located in cde-package/nmap.cde
Best regards
In gcc, this isn't supported. In fact, this isn't supported in any existing compiler/linker i'm aware of.