If I pass a lib name with -l option, then GCC will link to the best lib from /usr/lib. I think the dynamic version is chosen over the static version when both are present.
But there are also debug versions of the same lib. Debug versions are supposed to be compiled with optimisations off and extra runtime checks on. I checked it with the package manager (Synaptic on Ubuntu) that dbg versions are indeed installed on my computer, but not entirely sure where are those libs and how to link to them.
Any hints are greatly appreciated. Thanks.
If you are aware of the name of the debug library, you can directly use it in compilation instead of going with -l option. For example :
gcc -o <output_file> *.c <libdebug_file>.so
how about moving those libraries to a different path rather than standard ones and then compile using g++ with the -l (library-name option)
Related
Hi I am trying to compile a QT program I made for Windows statically with the openssl libraries compiled into the executable. I thought I succeeded however I can't run the porgram without the Openssl dlls present. I looked all over the net trying to find a solution but couldn't. Here's what I've done:
I passed this to configure.bat by editing the windows powershell script for building qt statically and then run it to build:
-openssl-linked
-I C:\OpenSSL-Win32\include
-L C:\OpenSSL-Win32\lib\MinGW
OPENSSL_LIBS=""-lUser32 -lAdvapi32 -lGdi32 -lCrypt32""
OPENSSL_LIBS_DEBUG=-""-lssleay32 -llibeay32""
OPENSSL_LIBS_RELEASE=""-lssleay32 -llibeay32""
The executable won't work without the openssl dlls now. Am I doing something wrong?
You're linking with the dynamic version of OpenSSL. You should link with the static one instead:
-L C:\OpenSSL-Win32\lib\MinGW\static
Answer from Shining Light Productions:
Dependency Walker will show you what DLLs your executable depends on.
The MinGW libraries are "built" using the VC++ DLLs as the source.
IIRC, there are no static MinGW builds (why the generated .a files are
so massive has always been a mystery to me).
By default, libboostpython.a is compiled without -fPIC. But I have to make a python extension and it is a dynamic library with -fPIC that links to static libraries.
How can I compile a static library (libboostpython.a) with -fPIC from boost.python?
There are a couple options you could use:
Compile boost from source and pass extra compiler options to bjam. E.g. bjam ... cxxflags='-fPIC'. That would compile every boost source file as position independent code.
Use boost in the form of shared libraries. In this case you probably want to ship boost shared libraries along with your application to make sure the appropriate version of boost is used. You can link your executable with '-Wl,-rpath,$ORIGIN' flag, so that when the dynamic linker searches for shared libraries required by your executable it looks for them in the directory where the executable is. See man ld.so for more details on $ORIGIN.
Note that if you already run bjam once you need to clear the targets first
it is helpful also to print the commands by applying -d+2:
./bjam clean &&
./bjam -d+2 link=static cxxflags="-fPIC" install
I'm using minGW on windows, trying to compile a c++ program. I've used sockets in there, so I'm trying to link (not include... I've already included winsock.h) the wsock32 library. I know that the -L switch is for linking but none of the following commands work:
g++ C:\program.cpp -Lwsock32.lib
g++ C:\program.cpp -LC:\windows\system32\wsock32.dll
g++ C:\program.cpp -lC:\windows\system32\wsock32.dll
g++ C:\program.cpp -LC:\windows\system32\wsock32.lib
what should I do??
The -L option is for setting the directory where the linker should look for libraries/dlls.
The -l option is for naming the libraries/dlls you want to link with.
That would mean
g++ C:\Program.cpp -LC:\Windows\System32 -lwsock32
should be the command to compile your program from your regular windows command prompt.
I suspect your compiler may look in system32 automatically, so you may want to just try to skip the -L option.
As #Joshua commented, you probably want ws2_32.dll.
The GNU Compiler Collection uses ranlib archives (A files) rather than Visual Studio LIB files.
The w32headers project provides gcc- and g++-compatible headers and archives for most standard Windows DLLs, including ws2_32.dll. The name of the archive is usually the name of the DLL minus the .dll extension, prefixed with lib and suffixed with .a (following the *nix archive naming convention). Thus, the symbols for ws2_32.dll are in libws2_32.a, which can be linked with using ‑lws2_32.
By default, the w32headers archives are in the GNU ld library path, so to be able to link with standard Windows DLLs, there is no need to add library directories with an ‑L option. In your case, the only option that you need is ‑lws2_32:
g++ C:\Program.cpp -lws2_32
Assuming that compilation and linking succeed, the output will be a.exe in the current directory. You can override the name of the output binary with the ‑o option.
NOTE: I used non-breaking hyphens in my answer. If you copy & paste the command line options, be sure to replace all hyphen-looking characters with regular hyphens.
How do I statically link the sqlite3 libary to my C++ program?
I am using the G++ compiler.
in Unix/Linux you'll have to make sure the library (e.g. libsqlite3.a) is in your LD_LIBRARY_PATH and then you add "-lsqlite3 -static" to the g++ option.
Assuming you're on Linux and using the GNU ld linker:
g++ <your-code> -Wl,--Bstatic -lsqlite3
Of course, if libsqlite3.a isn't in your library path, you have to pass the directory it's in to the compiler as an additional -L flag.
If you don't have a static version (I don't on my system), you either have to check if you can get one or if you'll have to build your own.
On a Linux system I recommend using pkg-config.
Running pkg-config --cflags --libs --static sqlite3 should give you the compiler and linker flags you need.
Go to www.sqlite.org and download the latest version's amalgamation tarball. Include their source files to your project (make file, whatever) and forget about it. It's embedded anyway, they compile in a jiffy, if you put into your version control repo, you know what version you're using in what version of your application and you can forget about linking options. Just remember that their source files are C and not C++.
I created a simple .so library containing definition of a C++ class which should be accessed from Python and used for this purpose boost python library.
When I'm testing this library using x64 Ubuntu it is enough to set LD_LIBRARY_PATH with the path to boost libs before running python. It doesn't work, however, when I'm using x64 Suse.
Altough I'm setting LD_LIBRARY_PATH it seems that Python ignores it.
Is there any specific way to set environmental variables under Suse?
You should never set LD_LIBRARY_PATH, see here and here.
First of all I have to assume that you installed the Boost libraries in a nonstandard location, otherwise the loader would find them automatically. If you have root access to the machine, install the libraries in a standard place (e.g. with the package manager, or in /usr/local/lib).
If you don't have root privileges, set the runpath instead. When using the gcc linker, do this by passing an -rpath option. The gcc compiler can pass options to the linker via -Wl. So call the compiler as follows:
g++ -Wall -Wextra -Wl,-rpath /path/to/boost -L /path/to/boost -lboost_python ...