I am using Windows 10 with mingw-w64. I tried compiling a program with a statically linked library. I used this command: g++ main.cpp -Llibs/ -lfoo. But MinGW says it can't find the library files, so I tried renaming foo.a to foo.lib and voila, the compiler found foo.lib. Why doesn't MinGW see *.a files anymore?
The problem is that mingw will not look for <libname>.a files because it does not expect them to exist.
From the docs:
MinGW supports libraries named according to the ".lib" and ".dll" conventions, in addition to the normal "lib.a" convention common on *nix systems
This is because windows does not use the lib prefix for its libraries in the same way that *nix does (on windows a shared library foo would be foo.dll and on *nix it would be libfoo.so). I am not sure how you managed to get a .a missing the lib prefix (unless you renamed it) but your .a files should have a lib prefix in them (when specifying this you omit the lib part so libfoo.a becomes -lfoo)
From the documentation:
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
xxx.lib
libxxx.lib
cygxxx.dll
libxxx.dll
xxx.dll
Alternatively, you can pass libs/foo.a directly as an argument to g++.
Related
I am relatively new to Linux development, having been using Windows for a while now. Anyway, I am compiling a C++ game using g++ on both Windows and Linux (using mingw32 when needed), and am linking against SDL2 and SDL2_mixer. On Windows, one would only need to put the DLL files in the same folder as the executable and everything would run fine. On Linux however, although the code compiled just fine with not even a single warning, I get this at runtime :
./nKaruga: error while loading shared libraries: libSDL2_mixer-2.0.so.0: cannot open shared object file: No such file or directory
although said shared lib is in the same folder. I looked up several similar cases on Stack Overflow, all of them involving the use of LD_LIBRARY_PATH, and tried it but to no avail.
% LD_LIBRARY_PATH=pwd
% export LD_LIBRARY_PATH
% ./nKaruga
./nKaruga: error while loading shared libraries: libSDL2_mixer-2.0.so.0: cannot open shared object file: No such file or directory
I want to distribute this program on systems that do not necessarily have admin rights to install dependencies, hence why I am putting the SO in the same folder as the executable.
Thanks by advance !
LD_LIBRARY_PATH is a quick ad-hoc hack to specify alternate library loading search paths. A more permanent and cleaner solution is to specify the specific sets of paths in which libraries shall be searched specific for your particular binary. This is called the rpath (Wikipedia article on it: https://en.wikipedia.org/wiki/Rpath). There are a number of "variables" that can be specified in the binary rpath that get substituted. In your case the rpath variable ${ORIGIN} would be the most interesting for you. ${ORIGIN} tells the dynamic linker to look for libraries within the very same directory in which also the binary resides.
The rpath can be set at link time with the -rpath linker option, i.e. when invoked through GCC the option would be -Wl,-rpath='${ORIGIN}', i.e.
gcc -o program_binary -Wl,-rpath='${ORIGIN}' -lSDL2_mixer a.o b.o …
For an existing binary the rpath can be set post-hoc using the chrpath or patchelf tools; it's better to set it at link time proper, though.
I use TextPad and MinGW. I compile with TextPad so I don't know how to use gcc ect. comands.
I got my library from here ftp://ftp.gnu.org/gnu/gsl/gsl-1.9.tar.gz and I have no idea what to do with it. In my MinGW folder there are bin, include and lib folders of course but I have no idea what to copy where.
And I don't know how to find out where MinGW searches for these libraries.
It would seem reasonable to copy .h , .a and .dll files where such files already are. It doesn't help that supposedly the same gsl are different from source to source and some include .dll and some don't.
I suppose the biggest problem is how do I tell MinGW where to search, since I found gsl that is already compiled and I could supposedly already use.
Assuming you have MSYS accompanied with MinGW, you can simply do:
./configure
make
make install
after
tar xzf gsl-1.9.tar.gz
cd gsl...
It will install gsl to the default directories. You may have to use -I/usr/local/include -L/usr/local/lib on the command line when compiling your program using gcc, because MinGW gcc does not recognize those standard locations.
I've been using libarchive in my project for some time now and it's working great, at the moment I am dynamically linking to it, so on Windows the libarchive.dll file has to present on the system.
I would now like to statically link to the library so I don't have to bother distributing the DLL, but I'm having real trouble trying to achieve this!
Currently, in my make file, I have something like this:
-Lpath/to//libarchive/ -larchive
And this works, but it does a dynamic link. I don't know how to enforce a static link.
I can see in the libarchive directory there are two a files, libarchive.dll.a and libarchive_static.a. I suppose I want to link to libarchive_static.a but I can't seem to specify this, doing -larchive_static in the make file results in linker errors.
I was under the impression that static libraries under windows are lib files, but I get no such file type when I build libarchive.
How can I make a .lib file from libarchive. Also, as an extra question, what is the difference between an a file and a lib file?
Update
To statically link to libarchive, your library command for make should contain:
-Lpath/to//libarchive/ -larchive_static
This will link to the libarchive_static.a file. However, you also need to define LIBARCHIVE_STATIC in your code.
Now the problem is that libarchive depends on the bzip2 libraries (as well as others), and if you do not have a static build of them you will get linker errors something like:
undefined reference to `BZ2_bzCompressInit'
You need a static build of the dependent libraries and a similar command to the linker after the libarchive command:
-Lpath/to/bzip2/ -lbzip2
You can either build bzip2 from source, or do it the easy way and get a pre-built binary from the Gnu32Win project here: http://gnuwin32.sourceforge.net/packages.html
Just add libarchive_static.a explicitly to your link command.
gcc -o YourApp.exe $(OBJS) path/to/libarchive_static.a $(OtherLibs)
".lib" files differ from compiler to compiler (Borland, Microsoft etc.), ".a" is an old "archive" format from UNIX's ar tool. It is now used only for the bundling of static libraries.
Currently, in my make file, I have something ...
And this works, but it does a dynamic link
The .a file actually contains some code for dynamic linking to the .dll file, not the libarchive itself. On the startup the pointers to functions are allocated and dynamic linking is done.
First I built the Boost libraries that require building by going to /usr/local/boost_1_49_0/ and running the bootstrap.sh. This went off alright.
Step (1) created all the .so and .a files in /usr/local/boost_1_49_0/stage/lib
I tested linking against a library, say lboost_regex and #include <boost/regex> in my source code. This also went off alright.
Finally trying out the example on asio, I tried:
g++ -I/usr/local/boost_1_49_0 MAIN.cpp -o MAIN -L/usr/local/boost_1_49_0/stage/lib -lboost_thread -lboost_system -lpthread
(4) compiled alright. But when I run the program with ./MAIN, I get the following error:
./MAIN: error while loading shared libraries: libboost_system.so.1.49.0: cannot open shared object file: No such file or directory
The -L option only sets a compile-time library search path; if you want a shared library to be found at runtime then its directory must be known at runtime.
One way to set this with g++ is to pass -rpath to the linker, via the compiler; in your case you could say -Wl,-rpath -Wl,/usr/local/boost_1_49_0/stage/lib. (This embeds the directory in the executable.)
Another way is to install the libraries in a place that the linker searches by default (e.g. /usr/local/lib might be such a place, depending on how the system is configured).
Yet another way is to set an environment variable such as LD_LIBRARY_PATH (Linux or Solaris) or DYLD_LIBRARY_PATH (Mac OS X), to tell the linker where to search when launching executables from the shell where the variable is set.
Are you sure the shared library is in a place where the loader can find it? Either put it in a system wide directory or the same directory as the executable.
Here's a link with more information about the loader.
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.