I am trying to generate a shared library (libgenerated.so) using g++ . The shared library uses some functionality that comes from a third party static library (libmystatic.a). For which I am linking the static library with the shared library as :
g++ -shared -o libgenerated.so $(OBJ_FILES) -lmystatic
The above command returns the following relocation error for the static library:
relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
Which points out that the object files in the static library needs to be compiled with -fpic flag. I am unable to understand why creating a Windows dll using the same static library (compiled for windows without -fpic) works ? I am using x86_64-w64-mingw32-g++ for the Windows DLL.
Thoughts from experts....
Which points out that the object files in the static library needs to be compiled with -fpic flag.
Exactly: on x86_64 you must compile code that is linked into a shared library with -fPIC of -fPIC.
I am unable to understand why creating a Windows dll using the same static library (compiled for windows without -fpic) works ?
There are two reasons:
On Windows, position-independent code is the default. So you get code compiled as if -fPIC was on command line regardless of whether that flag was on compile line or not.
The requirement to have position-independent code is architecture-specific. You can build a 32-bit i*86 shared library without -fPIC (this is ill-advised, but it works). On x86_64 (64-bit) Linux, you can't -- it simply can't work on that architecture.
Related
I'm trying to install SDL on MinGW.
I've downloaded SDL from here (the SDL2-devel-2.0.0-mingw.tar.gz link), then copied the contents of SDL2-2.0.0/x86_64-w64-mingw32/{bin,include,lib} into the matching directories in my MinGW installation.
When I try to compile any file that contains #include ‹SDL2/SDL.h› using gcc test.c -lmingw32 -lSDL2main -lSDL2 -mwindows, GCC complains about undefined reference to WinMain#16 and undefined reference to some SDL functions.
SDL2-devel-2.0.0-mingw.tar.gz contains both 32-bit libraries (i686-w64-mingw32 directory) and 64-bit libraries (x86_64-w64-mingw32 directory).
The error was caused by using a 64-bit version of the library with a 32-bit compiler.
I am having the following while making from source that also uses some static library during compilation. Here is the error:
/usr/bin/x86_64-linux-gnu-ld:/home/sajjad/Documents/Course/graphics/cmu/assignments/asst1_drawsvg/lib/libCMU462.a(base64.cpp.o): relocation R_X86_64_32S against symbol`_ZNSs4_Rep20_S_empty_rep_storageE##GLIBCXX_3.4' can not be used when making a PIE object; recompile with -fPIC
It has already been discussed here before, it says that I am trying to - "Linking dynamically against static archives". And it asking to compile with -fPIC while creating the archives. But I got the source with already generated .a (archive) file.
What flag do I have to pass inside cmake to build against a static library.
I'm trying to build a package from Fedora that can run on a RedHat 6 machine. So I need to build and static linking with some library that does not exist in RedHat machine.
I found that I can you -static-libgcc or -static-libstdc++ to link with static version of standard library but I don't know how to do with glibc.
How can I link to static library of glibc with CMake?
I know the question mentions glibc but for C++, since -static-libgcc and -static-libstdc++ are linker options, the correct way to set them in CMake is with target_link_libraries().
So you would set it like this, where MyLibrary is the name of your project:
target_link_libraries(MyLibrary -static-libgcc -static-libstdc++)
Given this, if you want complete static linking of glibc you would likewise pass the -static flag.
target_link_libraries(MyLibrary -static)
If you want more of a global setting:
set(BUILD_SHARED_LIBS OFF)
set(CMAKE_EXE_LINKER_FLAGS "-static")
However, bear in mind that glibc is not designed to be statically linked, and without a great amount of additional work, you won't wind up with a truly static package. Your use case of building "a package from Fedora that can run on a RedHat 6 machine" will not readily work by statically linking glibc.
I'm building a dll to use PocoNetSSL to get some data via an HTTPS endpoint. I need to call that dll via C# in Unity which runs an old version of Mono.
I am using mingw-w64 shell to build my dll. There is a package of the Poco libraries available via the package manager pacman and I am using that.
$ pacman -Qs 'poco'
local/mingw-w64-x86_64-poco 1.6.0-2
POrtable COmponents C++ Libraries (mingw-w64)
I can build an executable and it builds fine & runs fine hitting the https endpoint. I have openssl installed somewhere or it may have come with mingw.
My problem is that I cannot open the dll with LoadLibrary. I get a null pointer and I'm guessing it's a dependency problem. Here's my build commands and a snapshot of dependency walker. Is there anything I am missing here. I think I should be able to do this but maybe not?
sburke#sburke-pc MINGW64 ~/sandbox/hitaws
$ scons
scons: Reading SConscript files ...
msys
scons: done reading SConscript files.
scons: Building targets ...
g++ -o gdoaws.os -c -Wall -DPOCO_WIN32_UTF8 -I/mingw64/include gdoaws.cpp
g++ -o gdoaws.dll -Wl,-no-undefined -shared -Wl,--out-implib=libgdoaws.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive gdoaws.os -Wl,--no-whole-archive -L/mingw64/lib -lPocoNetSSL.dll -lPocoNet.dll -lPocoUtil.dll -lPocoFoundation.dll
scons: done building targets.
Assuming your loading a dynamic library code is correct your app is very likely trying to load different version of openssl dlls than Poco was built against.
In msys2 you can check a dynamic library dependencies by:
ldd /mingw64/bin/libPocoNetSSL.dll
which depends on:
LIBEAY32.dll => /mingw64/bin/LIBEAY32.dll
SSLEAY32.dll => /mingw64/bin/SSLEAY32.dll
Is this what you see in dependency walker?
The best workround for this problem is to copy above dlls to the folder where your executable is and always distribute them with your software.
I'm trying to use the ncurses library on AIX 7.1 to make use of panels which aren't included in the curses library that is standard on AIX. I have the ncurses library installed. The compile,link, and execute work fine with:
xlc ngoodbye.c -lncurses
The actual ncurses library is libncurses.a, which I understand is a static library. However, when I move the executable to another AIX host and execute I get:
Dependent module libncurses.a(libncurses.so.5) could not be loaded. Could not load module libncurses.a(libncurses.so.5). System error: No such file or directory.
How can I link the ncurses library so that the program will execute on other hosts where the ncurses library isn't installed? Note I'm using xlc on AIX, not gcc.
I've tried -bstatic but get link errors at compile time. Note that I'm not a developer so my experience in this area is limited. Thanks.
Both static and shared libraries in AIX are built as position independent (PIC). So even a "shared" library can be statically bound to an executable. You were on the right track with -bstatic, you just need to switch back to dynamic binding for the rest of the libraries you're linking to.
So try this for your final link:
xlc -o myexe myexe.o <other objects as needed> -bstatic -lncurses -bdynamic -lm <and other other libraries as needed>
I do this all the time to make sure that my production environment matches my development one.
Normally ".a" does mean a static library. However, in adapting the initial report (in 2008) describing the AIX 5 shared library configuration there was some miscommunication and ".a" was used for both static and shared libraries. That was finally corrected last year (see changelog).
AIX 4, by the way, used a much more complicated scheme, so shared libraries for ncurses were first implemented on AIX 5.
Packagers prefer shared libraries. So what you have is a shared library named libncurses.a (legal, but not conventional). This is not created with the archiver ar, but using the loader ld. To see that they are different, you can try
ar tv libncurses.a
(with the appropriate directory). Likely ar will say something like
ar: 0707-108 File libncurses.a is not an archive file.
while file may give a more informative message:
libncurses.a: executable (RISC System/6000) or object module not stripped
You can however build ncurses from source. In that case (no matter what version), the default builds static libraries. You need not install those into the system area, but can configure ncurses using the --prefix option to install into a different directory.
As suggested in another answer, there is a workaround using the -bdynamic and -bstatic options of AIX's ld (loader), e.g., changing
xlc -o foo foo.c -lncurses
to
xlc -o foo foo.c -bstatic -lncurses -ldynamic
However, this is partly dependent upon the loader's search path and the name of the archive. If the archive is named libncurses.a, the command works as given. If it is named libncurses.so (as in current sources), then this command is needed to link against the shared library:
xlc -o foo foo.c -brtl -lncurses
But this command (which one might suppose to provide the static linkage using the libncurses.so file) does not succeed:
xlc -o foo foo.c -brtl -bstatic -lncurses -bdynamic