I want to use CUDPP library in my project. I've downloaded sources from project page. Unfortunatly, when I ran "make", there was only static library build. I've looked into Makefile files and haven't found any dynamic lib configuration. I don't want to keep static library with the project - it's totally non-portable way.
My question is: how can I build .so dynamic library of CUDPP, without writing my own Makefile/compiling it manually? Maybe someone already did it?
EDIT: I've replaced "g++" with "g++ -fPIC", "gcc" with "gcc -fPIC" and "nvcc" with "nvcc -Xcompiler -fpic". When I unpack obj files from archive, and link them to shared lib, I've got no error. However, my application crashes at start, when linked with this library.
when you compile pass the flag -Xcompiler -fpic to nvcc. If you link against any cuda libraries make sure you've linked to the shared libs, otherwise you can't link it. Hopefully that's all you need.
Are you also using -shared to create the library? You shouldn't need to extract anything from an archive if it is working correctly.
If you run ldd on your executable it will show you what dynamic linking is required by the app and you can check that the -fPIC etc. worked correctly. Also make sure that the .so library is on your LD_LIBRARY_PATH (sorry if that's obvious, no harm in checking).
Related
Right now, I have a modified version of a open-source dependency library (mylib.a file) in my project and thus I have it statically linked via gcc command(s). I am getting the error that...
"statically linked applications require at runtime the shared libraries from the glibc version used for linking"
My translation: my static dependency library cannot dynamically use glibc; it must also be compiled and dynamically linked. Thus, I'm trying to compile and statically link glibc.
I've gather that they would need to be compiled, the *.a library placed in a folder within the project, the "-I//location//" added in for the include headers, and the "-L//location//" added in for the libraries themselves.
But, for the question itself...
How to you compile glibc (32-bit and 64-bit)?
Through open-source research, I've found this link and I have cloned the repo but I cannot find any documentation on how to actually compile it.
git clone git://sourceware.org/git/glibc.git
Any thoughts or suggestions are welcomed.
My translation: my static dependency library cannot dynamically use glibc; it must also be compiled and dynamically linked. Thus, I'm trying to compile and statically link glibc.
As n.m. pointed out, your translation is wrong.
You are trying to link a fully static executable, and GLIBC is warning you that such executable will not run correctly on any machine with a different version of GLIBC installed.
Instead of trying to build a fully-static executable, build it such that it uses libc.so.6 (you can still link mylib.a into such executable).
IF the reason you added -static to your link is that you have both libmylib.a and libmylib.so, and would like to link in the former instead of the latter, read this answer.
I'm building a library that needs to be dynamically linked to my project. The output is a .so file, so I think I'm on the right track. I'm concerned by the way it's being linked at compile time - by specifying the location of its makefile and depending on a bunch of macros, which I've never encountered before.
Can I assume that since I'm building a .so library (rather than a .a) that I'm in fact dynamically linking? Or is it possible for .so libs to be statically linked, in which case I need to rip apart the make/config files to better understand what's going on?
Thanks,
Andrew
I'm not familiar with internal structure of executables and shared objects, so I could only give some practical hints.
Assuming you use gcc, it should have -shared option when linking object files into library - this way ld (called by gcc) makes shared object instead of executable binary.
gcc -shared -o libabc.so *.o ...
When you link some application with this libabc.so it should link without errors and after that with ldd command you should be able to see libabc.so among its dependencies.
$ ldd app
...
libabc.so => ...............
I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install
I have a c++ project (g++/raw Makefile) designed for linux, I used to statically link everything which worked fine for ages. Now I want to build binaries both statically and dynamically linked. The following command is used in my Makefile to build the dynamic library (say libtest):
$(CXX) -shared -Wl,-soname,libtest.so.1 -o libtest.so.1.0.0 $(LIBTEST_OBJS)
The output is libtest.so.1.0.0 which has the so name libtest.so.1
I found at least a symbolic link libtest.so --> libtest.so.1.0.0 is required to link my client program that actually use the above generated libtest.so.1.0.0 library.
Here my question is if I want to build my software, what is the standard way of managing the above symbolic link? Clearly I don't want this extra stuff in my source directory, but it is required to build my client binary, shall I create it as a temp link for building the client then just remove it when done? or shall I create a directory to host the generate .so library and its links and leave everything there until I do "make install" to install them into other specified directories? Will be cool to now what is the standard way of doing this.
Or maybe the way how I generate libraries is incorrect? shall I just generate libtest.so (as actual library, not a link) to link my executable, then rename the library and create those links when doing ``make install''?
any input will be appreciated. :)
Certainly don't generate libtest.so as an actual link. Typically installing the shared library development files installs the .h files and creates a symbolic link libtest.so as part of some install script you have to write.
If you're not installing the development files, but only using the library in your build process of your binary, you just create the symbolik link from your makefile.
There's not that much of a standard here, some prefer to build artifacts to a separate build directory,
some don't care if it's built in the source directory. I'd build to a separate directory though, and keep the source directory clean of any .o/.so/executable files.
You might find useful information here
My suggestion is to use libtool which handles situations like this.
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.