I'm trying to create a shared object using a number of .O files created with the -fPIC command. When I run g++ with the -shared argument it appears to be trying to statically link to the libstdc++.a library, which of course fails. I'm trying to figure out why it's automatically trying to link statically when I'm not using the -static-stdc++ argument.
when I try creating the shared object I get the error ...libstdc++.a(ios) relocate R_x86_64_325 against 'vtable for std::ios_base': cannot be used when making a shared object
I ran G++ with the -V argument and received and can see LD receives the argument -lstdc++.
When linking together a single shared object, you need to do this from existing .o files. You can not do this from existing .so files; this would link those .so files to your .so file, but not into your .so file. So gcc seeks out and finds an archive of .o files (.a) and tries to link them. But since those are not compiled for relocation (no -fPIC), these can not be used to create .so files.
Your options are:
dynamically link your .so to the libstdc++ (and thus make it depending on the .so file that is installed in the system)
build .o files for libstdc++ and compile them with -fPIC then compile from those your .so file (here it does not matter if you use the .o files directly or an ar archive)
For the first (that I would recommend) option the following will suffice (it is from a makefile that I use for creating malloc/free intercepting .so files)
gcc -shared -lstdc++ -o your.so yourfiles.o
I'll bet it's finding the static library first in its library search path, or ONLY finding the static library. Make sure that the appropriate version of the shared version is installed and can be found. You can probably truss your g++ run to hunt down the order in which it's opening libraries.
Related
I've made program, which formats storage devices. However, when I've created library (for python GUI) based on this program it starts to show the error:
/usr/bin/ld: fdisk/libfdisk.a(la-label.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
libfdisk.a, which I use, has been built from source util-linux-2.35.
And when -lfdisk is used instead of libfdisk.a, it compiles with no errors.
Compiles with errors:
g++ file1.cpp file2.cpp ... -o package.name ... libfdisk.a
Compiles correctly:
g++ file1.cpp file2.cpp ... -o package.name ... -lfdisk
What the difference between these 2 ways?
But there is another, optional, question about fdisk. When I compile my program (not library) with -lfdisk, program can not create 2 partitions due to error 28 (returns from fdisk_add_partition(...)).
I'll share the code if it needs.
With -lfdisk the linker is asked to figure out which library file exactly to use.
The usual linkers on Linux will prefix lib and then search for files with .so or .a ending in the library path, which because you didn't specify any, will be the system library path (probably /usr/lib/ or similar). If a .so is found, it will be preferred for linking if a static link wasn't requested.
Your other method will explicitly add in the file named libfdisk.a in the current directory. That is a static library, not a shared one, and if you try to build a shared library from it, then you need to have compiled libfdisk.a with -fPIC or if you try to build a PIE executable at least with -fPIE. If you are trying to build a non-PIE executable, then neither flag is required. GCC may be configured to build PIE by default (as a hardening measure).
So you are probably linking two completely different files.
I want to start with a simple linking usage to explain my problem. Lets assume that there is a library z which could be compiled to shared library libz.dll(D:/libs/z/shared/libz.dll) or to static library libz.a (D:/libs/z/static/libz.a).
Let I want to link against it, then I do this:
gcc -o main.exe main.o -LD:/libs/z/static -lz
According to this documentation, gcc would search for libz.a, which is
archive files whose members are object files
I also can do the following:
gcc -o main.exe main.o -LD:/libs/z/shared -lz
It is not mentioned in the documentation above that -l flag will search for lib<name>.so.
What will happen if I libz.a and libz.dll will be in the same directory? How the library will be linked with a program? Why I need the flags -Wl,-Bstatic and -Wl,-Bdynamic if -l searches both for shared and static libraries?
Why some developers provide .a files with .dll files for the same modules, if I compile a shared library distribution?
For example, Qt provides .dll files in bin directory with .a files in lib directory. Is it the same library, but built like shared and static, respectively? Or .a files are some kind of dummy libraries which provide linking with shared libraries, where there are real library implementations?
Another example is OpenGL library on Windows. Why every compiler must provide the static OpenGL lib like libopengl32.a in MingW?
What are files with .dll.a and .la extensions used for?
P.S. There are a lot of questions here, but I think each one depends on the previous one and there is no need to split them into several questions.
Please, have a look at ld and WIN32 (cygwin/mingw). Especially, the direct linking to a dll section for more information on the behavior of -l flag on Windows ports of LD. Extract:
For instance, when ld is called with the argument -lxxx it will attempt to find, in the first directory of its search path,
libxxx.dll.a
xxx.dll.a
libxxx.a
cygxxx.dll (*)
libxxx.dll
xxx.dll
before moving on to the next directory in the search path.
(*) Actually, this is not cygxxx.dll but in fact is <prefix>xxx.dll, where <prefix> is set by the ld option -dll-search-prefix=<prefix>. In the case of cygwin, the standard gcc spec file includes -dll-search-prefix=cyg, so in effect we actually search for cygxxx.dll.
NOTE: If you have ever built Boost with MinGW, you probably recall that the naming of Boost libraries exactly obeys the pattern described in the link above.
In the past there were issues in MinGW with direct linking to *.dll, so it was advised to create a static library lib*.a with exported symbols from *.dll and link against it instead. The link to this MinGW wiki page is now dead, so I assume that it should be fine to link directly against *.dll now. Furthermore, I did it myself several times with the latest MinGW-w64 distribution, and had no issues, yet.
You need link flags -Wl,-Bstatic and -Wl,-Bdynamic because sometimes you want to force static linking, for example, when the dynamic library with the same name is also present in a search path:
gcc object1.o object2.o -lMyLib2 -Wl,-Bstatic -lMyLib1 -Wl,-Bdynamic -o output
The above snippet guarantees that the default linking priority of -l flag is overridden for MyLib1, i.e. even if MyLib1.dll is present in the search path, LD will choose libMyLib1.a to link against. Notice that for MyLib2 LD will again prefer the dynamic version.
NOTE: If MyLib2 depends on MyLib1, then MyLib1 is dynamically linked too, regardless of -Wl,-Bstatic (i.e. it is ignored in this case). To prevent this you would have to link MyLib2 statically too.
I have a Makefile for linux that I am porting over to Darwin. The makefile takes a bunch of .o files and links them together into a .so shared object. Okay, so I figured (am I wrong about this?) that the best analog for this in Darwin is the dylib. So I changed the -shared flag to -dynamiclib.
Now the code that I am linking together into the dylib depends on lots of external libraries. When I try to build the dylib, I get errors saying there are undefined references. But the Linux Makefile does not specify any of the -lwhatever or -L/path/whatever options in the build step that creates the .so file. Hm? Is this because when you create an ELF .so file, by default it leaves external references unresolved, and then when the shared library is loaded, it recursively loads shared libraries which are depended on by the shared library you are loading? Wouldn't it be the case that if the shared library depends on a .a or .o file, you would HAVE to statically link them into the shared library, otherwise you could not link at runtime? How can you get away with having undefined references in a library that is loaded at runtime, unless the references are also to dynamically loadable libraries?
Anyway so if I specify
-undefined suppress -flat_namespace
it doesn't require me to add those -l and -L options when creating the shared library. But I still don't understand how this can work ultimately.
This thread also discusses this issue. I think the key point is that in order to get the Linux-like linking behavior, you need to specify the "-undefined dynamic_lookup" flag. By default, the Darwin linker throws an error if there are any undefined references in a dynamic library. You can also use -U to set this behavior on a per-symbol basis. See 'man ld' for reference.
Use libtool.
libtool -dynamic -multiply_defined suppress -install_name `basename ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib` -o ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib ../../../../rlp/lib/universal-darwin9-gcc40/libbtd.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttrie.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtkey.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtunit.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtutilities.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtopts.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxcode.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtprops.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxml.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake3.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake5.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtac.a -lstdc++.6 -lgcc_s.10.4 ../../../../build_system/lib/universal-darwin9-gcc40/libgcc.a -lSystem -lSystemStubs`
I have a project in my IDE. I need to make a shared library of it to use in extensions. I don't want to make a copy of this project with shared-library settings. Is there any way to build a shared library using the object files (.o) from my already existing project? As I understand, I can write a makefile for this.
I assume you're on some sort of Unix and are probably using the GNU toolchain. In that case, to create a proper shared library, you'd need to compile your code using the position-independent code flags (-fpic or -fPIC) before you can create a shared library. Unless your .o files are already compiled with those flags, chances are you won't end up with a working shared lib.
If they already are compiled for position independent code, the usual g++ -shared ... should do the trick.
g++ -shared -fPIC -o myshared.so *.o
So after I ran libtool and got out a libfoo.lo and foo.o file from my library source, how do I convert the libfoo.lo file into a normal Linux shared library, like libfoo.so.1.0.0 so I can install and link to it on my target system?
From the outputs mentioned in the question, it looks like you ran libtool with --mode=compile mode. You will need to run libtool again with --mode=link to produce .a and .so libraries.
libtool is just a simple wrapper for gcc, ln ar and ranlib which is needed to produce libraries. All it does is run gcc adding the necessary options to ensure that your static and shared libraries are created correctly.
When compiling libtool inserts the -fPIC tag to ensure the necessary generation of position independent code needed for shared libraries. The .o files are normal object files that can be archived into a static .a file. The .lo files are object files with position independent code which can now be linked into a .so file.
When linking libtool will run ar to create a static library or ln to link the objects files into a .so shared library.
libtool also can install the library when desired using the --mode=install.
See http://www.gnu.org/software/libtool/manual/libtool.html for more info.
Please remember that when building an executable there are always two stages, compiling and linking.