I am trying to compile a simple C program using GCC with MPIR under MinGW on my Windows 7 machine. I installed MPIR successfully (I guess) with configure, make, make check and make install (did not use "sudo" - what is this?).
The program is called "mytest.cpp", sits in the top folder of MPIR, namely C:/MPIR/mpir-2.7.0/, where also "mpir.h" is sitting (is it "the" (correct one? are there several?) mpir.h?):
#include "mpir.h"
using namespace std;
int main ()
{
mpz_t z;
mpz_init(z);
return 0;
}
I tried compiling via
gcc mytest.c -o mytest -lmpir -I/C:/MPIR/mpir-2.7.0/
with the hope that GCC would then be able to locate mpir.h, "-lmpir" because a helpful developer told me to; but then it says:
"C:/mingw/ [...] /bin/ld.exe: cannot find -lmpir"
where "[...]" stands for some directory up-and-down-climbs inside the "minGW" directory. However, I am with the shell currently in the
C:/MPIR/mpir-2.7.0/ directory.
What is wrong? How to make GCC find the mpir files? Should the compile option "-I" be spelled differently? I also heard about some "-L" option but could not find that anywhere. Thanks.
Change
gcc mytest.c -o mytest -lmpir -I/C:/MPIR/mpir-2.7.0/
to
gcc mytest.c -o mytest -lmpir -IC:/MPIR/mpir-2.7.0/ -LC:/MPIR/mpir-2.7.0
You don't need a / in front of C: and the -L flag tells the linker where to find the library that you are linking to with -l flag.
Also, I would recommend using relative paths to your includes and libraries instead of absolute.
Ok, I fixed it.
Summarizing, critical points are:
- the order of the gcc options matter: "-o mytest" needs to go to the end, and "-lname" before but after the "-Ldir";
- the path should have ".libs" at the end because this is where the libraries are (even if they do not need to be named libmpir.a)
- (at least in MinGW) the working format is c:/MPIR/mpir-2.7.0/.libs (thus absolute, also from /usr/local/ or other places)
What worked was for example:
$ gcc mytest.c -Lc:/MPIR/mpir-2.7.0/.libs -lmpir -o mytest
$ gcc mytest.c -Lc:/MPIR/mpir-2.7.0/.libs -lmpir.dll -o mytest
Best.
Related
I am trying to cross-compile Windows software on Linux using mingw32-w64 and running it with wine. However wine cannot load the libstdc++-6.dll library file. I searched online and found out that you have to put the directory that contains the DLL file into the path registry. In my case, that directory is Z:\bin\i686-w64-mingw32\bin.
Then I tried to run the compiled file by using wine executable.exe and the output is:
0100:err:module:import_dll Loading library libstdc++-6.dll (which is needed by L"Z:\\home\\sunnymonster\\dev\\c++\\opengl-tests\\cmake-build-debug\\opengl_tests.exe") failed (error c000007b).
0100:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\sunnymonster\\dev\\c++\\opengl-tests\\cmake-build-debug\\opengl_tests.exe" failed, status c0000135
I have verified that I am using the correct wine prefix.
Additional information:
Linux distro: Manjaro Linux 21.2.5
Linux kernel: 5.16.14-1
There're multiple approaches. First, let's formalize the problem:
$ cat test.cpp
#include <iostream>
int main() { std::cout << "hello" << std::endl; }
$ i686-w64-mingw32-g++ test.cpp -o a && WINEDEBUG=-all,err+module wine ./a.exe
0024:err:module:import_dll Library libgcc_s_dw2-1.dll (which is needed by L"Z:\\tmp\\a.exe") not found
0024:err:module:import_dll Library libstdc++-6.dll (which is needed by L"Z:\\tmp\\a.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"Z:\\tmp\\a.exe" failed, status c0000135
Solutions:
Link the core libraries statically:
$ i686-w64-mingw32-g++ test.cpp -o a -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic
$ WINEDEBUG=-all,err+module wine ./a.exe
hello
Use WINEPATH env. variable to tell wine the additional paths to load dlls from. In the example I pass it the location with mingw dlls that wine complains about. It may be different on your system, you might find it by asking package manager to list files in mingw-g++/gcc packages (whatever it's called on your system). Multiple paths should be separated by semicolon.
$ i686-w64-mingw32-g++ test.cpp -o a
$ WINEDEBUG=-all,err+module WINEPATH=/usr/i686-w64-mingw32/sys-root/mingw/bin/ wine ./a.exe
hello
Install a Windows version of MinGW, and then use it to compile the app. However, from what I remember, if you want to distribute the executable produced, you still need to either statically link against MinGW libs, or provide them together with the binary. So the only difference to point 1 is that the binary should work under your WINEPREFIX with no modifications.
Using wineg++. I mention it solely for completeness, I think it's the least useful solution. It produces a Linux file, which in itself might be okay, one could use that for debugging. However, in my tests, I didn't manage to makewineg++ link against a dll, even though mingw links to the same dll without a problem. It seems to link against .so files instead, even though the application you build with it can load .dll files dynamically. Odd utility.
$ wineg++ test.cpp -o a
$ WINEDEBUG=-all,err+module wine ./a.exe
hello
This question already has answers here:
How to install c++ library on linux
(2 answers)
Closed 4 years ago.
I'm new to c++ and don't understand how to install a library on Linux (Mint). I want to use the GNU GMP library:https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithmetic_Library
I downloaded the tar.lz file and installed it with
./configure
make
sudo make install
If I try to compile it, I get the error message that the header file "gmpxx.h" wasn't found. Where can I find this file? How do I compile it with the -lgmpxx -lgmp flags? I tried something like:
g++ test.cpp -o test -lgmpxx -lgmp
If the library is using the Autoconf system (which your does) then the default installation prefix is /usr/local.
That means libraries are installed in /usr/local/lib, and header files in /usr/local/include. Unfortunately few Linux systems have those added for the compiler to search by default, you need to explicitly tell the compiler to do it.
Telling the compiler to add a header-file path is done using the -I (upper-case i) option. For libraries the option is -L.
Like so:
g++ test.cpp -I/usr/local/include -L/usr/local/lib -lgmpxx -lgmp
The above command will allow your program to build, but it's unfortunately not enough as you most likely won't be able to run the program you just built. That's because the run-time linker and program loader doesn't know the path to the (dynamic) libraries either. You need to add another linker-specific flag -rpath telling the build-time linker to embed the path inside your finished program. The front-end program g++ doesn't know this option, so you need to use -Wl,-rpath:
g++ test.cpp -I/usr/local/include -L/usr/local/lib -lgmpxx -lgmp -Wl,-rpath=/usr/local/lib
The options can be found in the GCC documentation (for the -I and -L and -Wl options), and the documentation for ld (the compile-time linker) for the -rpath option.
If you install a lot of custom-build libraries, you might add the path /usr/local/lib to the file /etc/ld.so.conf and then run the ldconfig command (as root). Then you don't need the -rpath option.
Now with all of that said, almost all libraries you would usually use for development will be available in your distributions standard repository. If you use them the libraries will be installed with paths that means you don't have to add flags.
So I recommend you install your distributions development packages for the libraries instead.
I wanted to use latest g++ compiler(4.9.1) on suse linux, but suse only supports an older g++ version. So, I took a latest source code from one of the gnu mirror sites and compiled it myself. Everything went fine. But when I tried to compile my test code using the built g++, the compilation fails with error,
"/root/home/include/c++/4.9.1/x86_64-unknown-linux-gnu/bits/os_defines.h:39:22: fatal error: features.h: No such file or directory".
I can find a "features.h" in "/root/home/include/c++/4.9.1/parallel", but I feel that it should be there in "/root/home/include/c++/4.9.1/" itself.
I copied "/root/home/include/c++/4.9.1/parallel/features.h" to "/root/home/include/c++/4.9.1/" just to see what happens. Now it complains with error "whcar.h" not found.
Have I missed something.
Here are the steps I followed to build g++.
1. /root/home/gcc_build/objdir# ../gcc-4.9.1/configure --prefix=/root/home/ --disable-multilib
2. /root/home/gcc_build/objdir# make -j16
3. /root/home/gcc_build/objdir# make install
4. /root/home/gcc_build/test# /root/home/bin/g++ --sysroot /root/home -m64 test.cpp
I resolved the issue by removing sysroot option and pointing c++ include and library path to my home directory. One thing I noticed was that the g++ source does not come with libc and c header files, and libc has to be installed seperately. But with sysroot option, g++ was trying to look all the header files in my home directory.
Below is the command I used to successfully compile the code.
/root/home/bin/g++ -I /root/home/include/c++/4.9.1 -L /root/home/lib64 -Wl,--rpath=/root/home/lib64 --std=c++0x -m64 test.cpp
Take a look at the GCC Directory Options. It is important to use the correct "specifier" as well (-isystem, -L, -B, -I etc)
I installed Boost via sudo apt-get install libboost-all-dev on the most recent version of Ubuntu. Now I want to compile a project that uses the Boost.Serialization library, which needs to be linked.
I've tried many variants of the following, without success:
gcc -I /usr/lib code.cpp -o compiled /usr/lib/libboost_serialization.a
and
gcc -I /usr/lib code.cpp -o compiled -l libboost_serialization
The error message is:
error: ‘split_member’ is not a member of ‘boost::serialization
`
What am I missing?
You are having troubles with compiling your code, not linking. On that stage it has nothing to do with libraries. At that point the fact that you have to link against something is irrelevant.
Make sure you are including boost/serialization/split_member.hpp directly or indirectly and get your code compiled first.
On a side note, -I flag is used to specify path to include files and not libraries. For libraries, use -L. But if you have installed Boost from apt, then it should already be in the path and so no additional -I or -L should be required. And when you specify -l, you have to emit lib from the beginning of library name and not put a space between a flag and its argument. Assuming working code, something like this should do:
g++ code.cpp -o compiled -lboost_serialization
I'd also recommend you pass -Wall flag to make compiler be more verbose and warn you about possible mistakes in your code.
split member is a problem with compiling where boost is assuming there are split calls for serialize and deserialize.
http://www.ocoudert.com/blog/2011/07/09/a-practical-guide-to-c-serialization/
I'm having trouble building a simple c++ program that tests out regex's from the boost library. The problem that I'm having is occurring in the linking stage and I don't know enough to fix the error on my own.
In the .cpp program that uses regexes I used the following include line.
#include <boost/regex.hpp>
I don't know enough to figure out what command I should use to build the program using g++. I tried using the following command line (and variations of it) to build the program.
g++ -I/usr/include/regex -L/usr/lib -llibboost_regex main.cpp -o regex_test
Other information that might be relevant:
Operating system: Arch linux
g++ version: 4.6.2 20120120 (prerelease)
Any help would be appreciated.
Assume you have installed Boost with the boost and boost-libs packages,
The header <boost/regex.hpp> should exist in /usr/include/boost/regex.hpp. You don't need to use any -I flags since /usr/include should be included by default.
You shouldn't need the -L flag either since /usr/lib should also be included by default when linking.
When using the -l flag to link with a library libfoo.so, the leading "lib" part should be removed.
The command line should therefore be:
g++ main.cpp -o regex_test -lboost_regex