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.
Related
Problem
I need my code to compile on a machine that cannot leverage apt-get to install nonstandard C++ libraries but my C++ program has a single #include for an external library that I must use. That library includes many headers and other libraries, meaning that my makefile has many -l and -I to /usr/include/... and /usr/lib/... pointing to my apt-get installed libraries.
What I want
Rather than manually going through and grabbing all of these libraries so that I can include them in my project directory, I am hoping there is a command or flag for make or g++ that will dump all the libraries and headers into a directory for me.
Progress
This and this have helped because adding the -MMD flag to my g++ compile command will dump out a list of about 100 header file locations. But I would like g++ to go one step further and actually do the work of gathering them all together for me, if that feature exists.
im trying to port a c++ project from visual studio 2013 to netbeans on ubuntu. The target is a windows executable, so far im able to compile windows exe files from netbeans using mingw as compiler.
The project needs the Crypto++ library and i only have the .lib version for visual studio. To include the library in netbeans i first need to build the Crypto++ library in the .a format.
Its not clear to me how should i do that.
Ive found informations on how to build the library for linux with mingw but not for cross compilation with mingw. The provided GNUmakefile does not work.
Should i set up a vm with windows and mingw and compile the library that way? Or maybe use the qmake "hack" as suggested here http://www.qtcentre.org/threads/28809-Compiling-amp-using-Crypto-with-mingw-version-of-Qt ? The last good Crypto++ version suggested there is quite old. This is confusing, porting the whole project is easier than having the required library.
Im open to any suggestion.
tldr: how to build libcryptopp.a on linux for the cross compilation of a windows exe project
edit:
for example if i cross compile something there are windows libraries in the /usr/i686-w64-mingw32/lib/ folder like libuser32.a. i need to make the equivalend libcryptopp.a.. sorry if is a bit unclear.
if i simply build using the steps in answer (and in the wiki) i end up with a libcryptopp.a file but i suspect is linux-only, cause if i link that library in netbeans in the .exe file im cross compiling i end up with undefined references to cryptopp stuff everywere. the paths are correct, i suspect the library needs to be replaced with the equivalent libcryptopp.a compatible with crosscompiling.
edit2: im trying to follow the answer down here, now im stuck here. after this command to build cryptopp.
make CXX=/usr/bin/i686-w64-mingw32-gcc INCLUDES="-I /usr/i686-w64-mingw32/include" LIBS="-L /usr/i686-w64-mingw32/lib" CXXFLAGS="-std=c++0x"
and many variations of it i always end up with this error
trap.h:26:25: fatal error: Windows.h: No such file or directory
# include
which makes me think its using the right compiler to make a .a lib file for cross compiling the windows .exe with the lib.
however i dont understand whats going on now with the missing header..:(
Also if i try to link the lib file (used with visual studio) i get a lot of linking errors, undefined reference to cryptopp stuff.
ill offer a symbolic beer (a couple of $ of Bitcoins) if someone finds out how to do it.
Inspired by http://wiki.amule.org/wiki/Cross-compilation_for_windows_with_mingw:
sudo apt-get install mingw-w64
git clone https://github.com/weidai11/cryptopp
cd cryptopp
export TARGET=i686-w64-mingw32
CXX=$TARGET-g++ RANLIB=$TARGET-ranlib AR=$TARGET-ar LDLIBS=-lws2_32 make -f GNUmakefile
I've found informations on how to build the library for linux with mingw but not for cross compilation with mingw.
Its relatively easy...
Get Crypto++ ZIP into MinGW.
Unpack Crypto++ ZIP.
Change directories.
Build the library.
Verify All tests passed.
(1) and (2) can be tricky because Cygwin and MinGW are missing a lot of tools. So curl https://www.cryptopp.com/cryptopp563.zip -o cryptopp563.zip may not work.
For (2), I seem to recall ZIP is missing, so unzip -aoq cryptopp563.zip -d cryptopp-5.6.3 may not work.
At step (4), just perform make static dynamic test and be sure it finished with All tests passed.
I do a lot of testing with Cygwin and MinGW. I have a script that copies Crypto++ into the environments from my Desktop. I have not been able to figure out a way to automate it. A recent question on automating it was closed, so no one can supply an answer (see How to automate software testing for Cygwin and MinGW).
I am trying to build libtorrent (http://www.libtorrent.org/) using the provided jamfile. If I try to build it in its vanilla state everything goes well. I am then building using this command:
bjam msvc-12.0 boost=source
However I want to build it with OpenSSL which there seem to be support for. This is where I run into problems. Most likely because it is the first time I use Bjam (actually anything else than make files). I now try to run the following command:
bjam msvc-12.0 boost=source encryption=openssl
Now the compiler starts to complain about not finding the OpenSSL include files.
So I guess I have to include this path in the JAM file. But I have no idea where.
I also tried to add the path into the INCLUDE environment varaible in windows but that doesn't seem to be picked up by BJAM or msvc. Any suggestions?
My understanding of how this is normally done on windows is by installing libraries and headers into visual studio's include and lib folders.
(That's how I install openssl on windows at least).
The jamfile is also supposed to pick up CXXFLAGS and LDFLAGS environment variables, which you could use to introduce the library- and include paths. However, it only does this when boost=system is specified, i.e. you're building against "system" boost libraries instead of from source.
C++-Protobuf does not compile in VS2012. Now I want to use MinGW to compile it on windows. Can someone please give me some brief headwords on how to compile protobuf on Win7 x64. I already installed MinGW with the GUI installer. Google writes as MinGW setup notice that I should refer to the Unix installation notes. But I cant figure out how to use the auto tools on windows.
Edit
Okay this is what I've done until now:
$ mount C:/ WinDir
$ cd ./[...]/protobuf.2.4.1
$ ./configure
$ minGW32-make.exe
$ minGW32-make.exe check
minGW32-make.exe runs without errors, but no tests are running and I cant find libprotobuf.lib. There are some libprotobuf.dll but I need the lib, dont I?.
You should have an MSys console together with your MinGW instalation. This console provides an linux-like environment in which you should be able to use autotools normally.
If MSys is not installed, you can grab it from the MinGW site too.
cd to your directory with sources and try the usual:
$ ./configure
$ make
Some libraries cause problems on Windows but most compile well with MinGW and MSys. Come back and add more info to your question if you run into specific problems.
Edit:
minGW32-make.exe runs without errors, but no tests are running and I cant find libprotobuf.lib. There are some libprotobuf.dll but I need the lib, dont I?.
Usually for a dynamic library you'd get protobuf.dll (the dynamic library) and libprotobuf.a (the static wrapper library).
When linking, just pass -lprotobuf to the linker - it will look for both libprotobuf.a and protobuf.lib.
(.lib is another static library format, which is partially handled by MinGW but not native here.)
You will not work with a .lib file when using the MinGW toolchain. Instead, you are able to link against the dll directly. The MinGW Wiki explains this.
I could get dll and lib both. This is when you do not want static lib file and want to use dll and lib file.
You need to make following changes in Protobuf code:
Open the project in VS. Or any other editor. I use VS2015.
In libProtoBuf project settings, in C/C++ Preprocessor add following flags.
PROTOBUF_USE_DLLS; LIBPROTOBUF_EXPORTS;
Those flags will export information from profobuf using dllexport
in ur client code where you are using Protobuf, define: PROTOBUF_USE_DLLS. Which will make protobuf includes to use dllimport.
Once you do step 2, you will see both dll and lib in your output folder. Otherwise, you will always see just dll and not lib file.
Hope this helps. If not, please write a message here and I can help you getting this sorted out.
So suppose I have installed the SFML 1.6 C++ library from the Ubuntu repositories. Then I have header files in /usr/include/SFML, library files in /usr/lib etc.
Now I have also downloaded a recent source tarball and built and installed SFML 2.0 into /usr/local.
So by default, if I #include , it gets the SFML 2.0 copy from /usr/local/include. Similarly, it links to libraries from /usr/local/lib.
My question is, how can I tell the compiler/linker to get the files from /usr/include and /usr/lib? I tried
g++ -I/usr/include
but it didn't work. Is this possible at all? Or should I just keep the 'home built' copy in a non system location?
Check the ldconfig command. I guess running it in the destination folder of the newer version of the library should do the trick.