I'm currently trying to compile a dynamically linked library (for a plugin system) using Windows and MinGW.
I compile each objects using this command line :
mingw-g++ -fPIC test.cpp
And the library using this line:
mingw-g++ -rdynamic -shared -Wl,-soname,test.so.1 -o test.so test.o
It doesn't work at all (using GCC with Linux, a similar line works though) : fPIC and rdynamic are ignored for some reason.
And while trying to make the library, it fails because the compiler try to link it with objects that are supposed to be resolved as I dynamically link it with the main binary.
So how do you compile this using MinGW?
Thanks :) !
-fPIC and -rdynamic are ignored because they are unused for Windows.
Also, .so is not the correct output extension for libraries on Windows.
To make a shared library for/on windows with GCC:
mingw-g++ -c file.cpp -o file.o
mingw-g++ -shared -Wl,--out-implib,libfile.a -o file.dll file.o
No more, no less.
And, documentation is always lovely to have: http://www.mingw.org/wiki/sampleDLL
Related
I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html
I am trying to compile a multi threaded application to WebAssembly. The application uses OpenMP for multithreading.
To compile I am using the Emscripten framework.
I have already downloaded the source files for OpenMP and compiled it for my host machine using make. With the following command I can get it to link with a simple demo application on my machine:
g++ -Wall -Werror -pedantic main.o -o main.x /$PATH_TO_OPENMP/build/runtime/src/libgomp.a -pthread -lstdc++ -Wl,--no-as-needed -ldl
I then tried to compile OpenMP to the llvm bytecode format used by Emscripten. To do so I tried to run 'emmake make', so that the emscripten framework executes the OpenMP makefiles with a suitable compiler. As emscripten does not like shared object files I compiled it to static library .a files.
This works and actually gives me object files to which I can link.
I then wanted to link my demo application with the following command
em++ -Wall -Werror -pedantic main.o -o main.html /home/main/data/Programming/openMP/openmp_web/build/runtime/src/libgomp.a -pthread -lstdc++ -Wl,--no-as-needed -ldl
But I get these warnings, that it couldn't link to OpenMP files:
shared:WARNING: object /tmp/emscripten_temp_ONa0eU_archive_contents/kmp_atomic.cpp.o is not a valid object file for emscripten, cannot link
.
.
shared:WARNING: object /tmp/emscripten_temp_ONa0eU_archive_contents/kmp_str.cpp.o is not a valid object file for emscripten, cannot link
shared:WARNING: object /tmp/emscripten_temp_ONa0eU_archive_contents
So I figured I must have compiled OpenMP with the wrong compiler. I then tried to change the compiler when building the library by using the following commands:
cmake -DCMAKE_C_COMPILER=emcc -DCMAKE_CXX_COMPILER=em++ -DLIBOMP_LIB_TYPE=normal -DLIBOMP_ENABLE_SHARED=OFF -DCMAKE_BUILD_TYPE=Release -DLIBOMP_ARCH=x86_64 OPENMP_STANDALONE_BUILD=1 ..
emmake make
But this just gives strange errors on some missing system variables
/home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_platform.h:82:2: error: Unknown OS
/home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_platform.h:203:2: error: Unknown or unsupported architecture
In file included from /home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_alloc.cpp:13:
In file included from /home/main/data/Programming/openMP/openmp_web/runtime/src/kmp.h:77:
/home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_os.h:171:2: error: "Can't determine size_t printf format specifier."
Does anyone have an idea on what I could do differently?
In GCC, if I compile something into a shared library with GCC with g++ -shared func.cpp -o libfunc.so -fPIC, internal function calls to global symbols go through GOT in this generated shared library file. But if I compile with g++ func.cpp -o libfunc.so -mcmodel=large, it will not generate GOT but instead relocate by patching with R_X86_64_64 style relocation directly.
I want this behavior for executables as well. If I compile an executable with g++ main.cpp libfunc.so -o a.out, GCC will generate GOT for any function call from main.cpp to one defined in libfunc.so. I don't want this behavior. I want R_X86_64_64 style relocation. How can I achieve that?
Executables are compiled with -fPIE by default in modern distros for security reasons. To get old behavior add -no-pie to CFLAGS/CXXFLAGS.
I've been trying to find the proper .a's and related flags for statically linking an app or SO under Linux. I know -static exists, but I can't use it as there's one specific SO I must link to.
To put it another way, I'm looking for the appropriate flags to statically link everything, except for a specific SO.
Thanks.
At my workplace we use -Bstatic and -Bdynamic but they are options to the linker ld. You can specify them with gcc using the -Wl option.
g++ -o app -Wl,-Bstatic -llib1 -llib2 -llib3 -Wl,-Bdynamic -llib4 app.o
Above shows command line for linking with lib1, lib2, and lib3 as static libraries and lib4 as a shared object library.
I'm seeing:
ld: in objs/AttributeValueTest.o, can't link with a main executable for architecture x86_64
When building a very simple program which has only 1 .h and 1 .cpp file.
The compile lines are:
g++ -g -I./ -I/usr/local/include -o objs/AttributeValueTest.o tp_datastruct/tests/AttributeValueTest.cpp -L/usr/local/lib -lavrocpp -lcppunit -lm
g++ -g -I./ -I/usr/local/include -o AttributeValueTest objs/AttributeValueTest.o -L/usr/local/lib -lavrocpp -lcppunit -lm
I tried to specify -arch x86_64, -arch i386 and -m32, but nothing worked (I got other errors, it was complaining that libcppunit was not in the right format).
Any idea/pointer/suggestion?
Thanks!
Very strange. I did some digging around, and saw somewhere that AttributeValueTest.o might be an executable already. I did a "file" on that AttributeValueTest.o, and sure enough, it is a ready-to-go executable. I modified my makefile to rename that .o into AttributeValueTest, and I can happily run it. Also, the executable comes with a ".dSYM" directory, which I can remove without any problem... I don't understand what is going on, but I can run my executable now...
You forgot to specify -c option to the g++ to compile a source code into object file. So it is getting compiled and linked into executable file. Then you are trying to link executable into executable, which fails. From the gcc's manual page:
-c Compile or assemble the source files, but do not link. The
linking stage simply is not done. The
ultimate output is in the form of an
object file for each source file.
By default, the object file name for a source file is made by
r> eplacing the suffix .c, .i, .s, etc.,
with .o. Unrecognized input files, not
requiring compilation or assembly, are
ignored.