I was recompiling the existing source files but it is not able to create the executable though it file generated has execute permission
-rwxrwxr-x 1 ilvweb ilv 2949112 Jan 31 09:34 karny
$ file karny
karny: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped
The command used for compilation
g++ -m64 -mcpu=v9 -DSUNOS -DNDEBUG -g -Wno-deprecated -o karny tkm.o THlm.o Connection.o Socket.o ThLogger.o File.o TextFile.o File.o Timer.o lPlugin.o \
-G -lm
Is there any option missing
If we have both gcc and g++ and the source written for g++ in order to recompile with gcc what could be done as the as the currently in this environment we can use only gcc
According to the GCC manual:
3.17.41 Options for System V
These additional options are available on System V Release 4 for
compatibility with other compilers on those systems:
-G
Create a shared object. It is recommended that -symbolic or -shared be used instead.
[... snip ...]
Seeing as you're on (SysV-derived) Solaris, it would seem you're asking GCC to create a shared object. Is there a specific reason you have that -G?
According to file, you made a shared object (which usually would be named *.so).
Related
I am creating a gcc shared library having a static library dependency.
I compile the parts for static library as following:
gcc -c -m64 -O2 -fPIC -std=c99 -Wall ms*.c //there are 10 C files, no warnings
Next I create a static library with:
ar rc static_lib.a ms*.o
Next I compile the parts for my program as following:
g++ -c -m64 -O2 -fPIC -std=c++14 -Wall ab*.cpp //there are 5 C++ files, just -Wunused-variable warnings
Then I create a shared library as following:
g++ -shared -g -Wall ab*.o static_lib.a -o shared_lib.so
in the normal case, this shared_lib.so will be called by a Ruby program using a foreign function interface. There is no problem if I do it on ubuntu or mac(.dylib), but if I try this on debian stretch I get an error related to the static library as if the configurations are not set properly. If I run the application without foreign function interface, such as creating a tester and running with the cpp file main function as following:
> g++ -o library_test ab*.o static_lib.a
> ./library_test
There is no problem!
My question is what kind of configuration for creating a shared library may be missing here to not get that undesirable behaviour. Especially on debian stretch 9.5!
Or is there a way that I can understand if there is a problem in the shared library.
From the comments, you indicate the problem is with a #define. Those are preprocessor directives. Libraries are for the linker.
You might be confused because g++ does include the preprocessor phase, and might call the linker depending on the requested output. Still, g++ follows the C++ language rules.
I am using mingw 64 bit with cygwin.
I know that if I compile using
x86_64-w64-mingw32-g++.exe -std=c++11 hello.cpp
the output .exe does not run unless the library path to libstdc++ and other libraries is specified in the Path environment variable.
An alternative is to link statically
x86_64-w64-mingw32-g++.exe -std=c++11 hello.cpp -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread
Since I want a single .exe that I can easily copy on different machines, the second solution is better for me. My only problem is that, since I link statically, even for a simple helloworld program, the size of the executable rises to more than 10 Mb. So my question is: is it possible to link statically only the library parts that are actually used by the program?
The binutils linker on Windows, ld, does not support the --gc-sections argument properly, which in combination with compiler flags -ffunction-sections and -fdata-sections, allow the linker to throw away blocks of unused code.
You are straight out of luck. The only thing you can do is the usual: strip the executable (by running the strip command on it after it is linked) and compile your code optimising for size with -Os.
Keeping in mind these options do not work on Windows (which for the purpose of this answer, includes the Cygwin platform), this is generally how you can do this:
g++ -c -Os -ffunction-sections -fdata-sections some_file.cpp -o some_file.o
g++ -c -Os -ffunction-sections -fdata-sections main.cpp -o main.o
g++ -Wl,--gc-sections main.o some_file.p -o my_executable
I'm trying to build a self contained executable, which I can run on any/most linux host.
I know I can do that with containers, but for now I'm trying to just statically link my exe.
I compile with:
g++ -std=c++1y -fopenmp -Ofast -g -march=x86-64 -mtune=generic -m64 -c <source>.cpp -MMD -MP -o <object>.o
And link with:
g++ -std=c++1y -fopenmp -Ofast -g -march=x86-64 -mtune=generic -m64 <list of object files> <list of absolute path to static libs .a> -lpthread -static-libgcc -static-libstdc++ -o exe
It used to work just fine, but I just discovered it now breaks on some hosts with
error while loading shared libraries: libmvec.so.1: cannot open shared object file: No such file or directory
I don't know if it's something in the code or system libraries update. I have tried (to no avail):
removing -fopenmp
adding -lmvec -lm to the linker
My exe is indeed statically linked: ldd exe says not a dynamic executable. But it insists on loading libmvec.so at runtime: strace exe says:
execv
a bunch of mmap
open(ld-linux-x86-64.so), read it and close it
open(ld.so.cache), stat, mmap, and close it
open(libpthread.so), read, stat, mmap and close it
open(libmvec.so) => fail on hosts where it doesn't exist
[...]
As I understand libmvec is an extension of libm, dealing with x86 vectorization, used by OpenMP.
So basically, I'm asking if there is a way to make it work statically - I see at least 3 solutions:
disable its use - but that would probably mean performance loss, plus it is used even when I disable OpenMP
statically link it, and somehow explain to the runtime that it then doesn't have to dynamically link to it since it's already linked.
make it optional, i.e. dynamically select a slower code path if it's not available. This sounds complex but could in theory be possible.
I have two Executable generated with different gcc version
One is using gcc 3.4.2 and other using gcc 4.3.2 in my Linux box
Both has to be run in same environment i.e. having same LD_LIBRARY_PATH.
Currently path of 4.3.2 is placed before the 3.4.2 the 3.4.2 is giving error.
libstdc++.so.6: version 'GLIBCXX_3.4.9' not found (required by../../src/hello)
I am thinking about the solution where I can store the information in the exe where to find the
loadtime files needed.
I created below build scripts which are giving problem:
Basically O3 option is doing optimization.
/opt/gcc-4.3.2/bin/g++ -pipe -O3 -c hello4_3_2.cpp
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -L$/opt/gcc-4.3.2/lib64/libstdc++
/opt/gcc-3.4.2/bin/g++ -pipe -O3 -c hello3_4_2.cpp
/opt/gcc-3.4.2/bin/g++ -o hello3_4_2 hello3_4_2.o -L$/opt/gcc-3.4.2/lib64/libstdc++
Below script works for me:(With out O3 option)
/opt/gcc-4.3.2/bin/g++ -pipe -c hello4_3_2.cpp
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -L$/opt/gcc-4.3.2/lib64/libstdc++
/opt/gcc-3.4.2/bin/g++ -pipe -c hello3_4_2.cpp
/opt/gcc-3.4.2/bin/g++ -o hello3_4_2 hello3_4_2.o -L$/opt/gcc-3.4.2/lib64/libstdc++
Now:
I wanted to know if there is any other way to achieve it.
Is there is any draw back of doing in this way.
Specify an rpath when linking:
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -Wl,-rpath,/opt/gcc-4.3.2/lib64
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This will hardcode a library search path into the executable.
You can use ldd ./hello4_3_2 to check without running whether the correct libraries are being found.
The libstdc++ manual lists several options
LLVM provides 2 tools llvm-link and llvm-ld. I would like to know:
how merge all .o file in one ?
how set a soname like with gcc -Wl,-soname,libsomething.so.1 ?
I would like do this in c++ but if show to me how do that from command line i will found how do to do in c++.
thanks
llvm-link is a tool for linking (~ merging) LLVM IR files into another LLVM IR file.
llvm-ld tries to be compatible to ld. Note that LLVM currently has no real linking capabilities, so llvm-ld calls gcc to do the actual final stages.
Note that if you just want to have GCC's functionality, use the clang driver:
clang -c file.c -fpic
clang -shared file.o -o file.so
You can also pass the -Wl flags to clang as you'd do for gcc:
clang -shared file.o -Wl,-soname,libfile.so.8 -o file.so