So I'm using Anaconda to run Python 2.7 32-bit on my company's server. That works dandy. Anaconda came with MinGW, so I'm attempting to use the g++ compiler in there. Everything works for me. I can compile c++ source, and then run the resulting executable. The issue comes when coworkers try to do the same. Apparently, the g++ compiler creates a dependency for the executable it makes on a particular dll located within Anaconda. I have a path variable to where this dll lives, my coworkers do not, thus, they cannot run any executable made by g++.
Is there a way to specify where this dll dependency is when I compile executable so that anyone can use them? Something like:
g++ someCode.cpp -o someCode.exe locationOfDll=path2dll
Just to be clear, everyone can successfully compile c++ source code, but only I can run the resulting executable. Thanks in advance
EDIT: I forgot to mention that simply giving everyone the path variable is not an option.
Does this help? It discusses updating the library search paths.
http://www.mingw.org/wiki/HOWTO_Specify_the_Location_of_Libraries_for_use_with_MinGW
Related
I'm using ortools in c++ to model a vehicle routing problem. I was wondering whether there was a way to compile the code using my own Makefile by including the proper flags for the compiler, so that I don't have to use
make build SOURCE=/path/to/my/program
I have compiled ortools from source on Debian 10, making sure to follow the proper instructions on the guide (make third-party then make cc then make install_cc). make test_cc runs and finished without problems, so I don't think there is any issues with the installation.
The only clue that I found about this topic was someone writing they used
g++ -std=c++11 -o my_program my_program.cc -I/usr/local/include/or-tools -lortools
to compile their program, but upon trying that, I have a lot of undefined references. I have read somewhere that one should use -std=c++17 instead of -std=c++11 but either way it does not work.
Please let me know if you need more details.
All binary packages comes with a supplied makefile.
You can see the source here: https://github.com/google/or-tools/blob/stable/tools/Makefile.cc.java.dotnet
If you run make detect_cc. It will print out all compiling and linking options for your platform.
Since ortools is a shared library, you will have to specify its path using the environment variable LD_LIBRARY_PATH in addition to specifying the path using the -L flag.
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:<path-to-lib>.
You can put the export command above in the .bashrc file or run it every time your run the code. Also, you will have to used C++17.
As the title says, I've been trying to cross compile a fairly large project with quite a few dependencies (both static and dynamic libraries). I've cross compiled every dependency successfully using MinGW-w64, set the include & library search paths to their MinGW counterparts (/usr/x86_64-w64-mingw32/lib & include), and yet on the linking step MinGW throws out an error for each call of printf (with stdio.h included, of course). The errors are as follows:
/usr/bin/x86_64-w64-mingw32-ld: ./obj/XXXX.o:/usr/share/mingw-w64/include/stdio.h:352: undefined reference to `__imp___acrt_iob_func'
(Where "XXXX" is a file name from my project)
This error is repeated the exact same (with the exception of the object file name). The command for linking looks like this:
/usr/bin/x86_64-w64-mingw32-g++ -o bin/ReleaseWin/Project #[file with object file names] -L. -L/usr/x86_64-w64-mingw32/lib/ [linking some dependencies (boost, openGL, SDL2, etc.)...] -m64 -flto
I've searched for a solution (or even someone with the same problem) to no avail. I've never been well-versed in linking any more than regular libraries, so if you need more information just ask.
Thanks in advance :)
Extra info:
This project has been cross compiled (from Linux to Windows) successfully before, and I haven't added/removed any dependencies since.
My MinGW-w64 version is 7.0.0
So, I apt-get purge'd mingw-w64 and mingw-w64-common, reinstalled just mingw-w64, and now it's working...
This might have something to do with the fact that I followed the issue that Richard Critten commented with (thanks!), which led me to try downloading and manually copy/pasting headers and CRT (mingw-w64-x86_64-headers-git-... & mingw-w64-x86_64-crt-git) from the MSYS2 repository. That didn't work right away (probably because I screwed up and used the 5.0.0 versions instead of my version), but it seems to have done something.
Therefore, for those who stumble upon this issue,
Try a re-install of MinGW (of course),
Try manually adding the CRT and headers from the link I supplied, and if that still doesn't work,
Try re-installing MinGW again. I'm not super familiar with apt, so I don't know if adding the CRT and headers actually changed how it installed MinGW, but it's worth a shot I guess.
Update: I had this exact same problem on another system. Simply reinstalling MinGW fixed it, so it seems like maybe there was some sort of issue with the files? It's possible that updating from an earlier version messed with things. Moral of the story: even if you think your files are good, a reinstall can't hurt.
We are doing a C++ project for our uni and its final phase is passing the whole thing into a graphical interface using Qt.
We use Qt5.4 and g++-5. These values have been set in the QtCreator project configuration by selecting the appropriate compiler, g++-5, and also adding options in the *.pro file such as -std=c++14 and so on.
Nevertheless we are being stumped by an important issue. No matter what we try, when running qmake so as to auto-generate the precompiled files, in any Makefile generated by it, the compiler is ALWAYS set to g++ and not g++-5. We are at the moment obliged to after using qmake having to change by hand the compiler in the Makefile on our own, even though we have told it EVERYWHERE that we are using g++-5 and not the normal g++.
We have tried solutions like in this question: Using c++14
And also changing the compiler in the mkspecs of the Qt SDK.
Both have been to no avail and we still can't get the auto-generated Makefile to use g++-5 unless we change it by hand.
Is this a Qt issue or are we doing a step incorrectly?
Thanks in advance.
Sorry for all the bother.
It is solved now, I had linked my g++ compiler to g++-5 when I installed it ages ago but had forgotten (both g++ and g++-5 work on my pc, but they are the same) so it wasn't being an error, just my pc configuration getting in the way, thanks for the help though.
I have a code on my computer uses Petsc which depends on mpi. On my computer it works well. I put it on cluster, exported paths of gcc, Petsc and openmpi (although I was using mpich on my computer I hope openmpi will also work) to LD_LIBRARY_PATH and PATH. I also changed paths in makefile. Petsc, gcc, openmpi were all available on cluster so I did not configure anything. When I did make, compiler gave error:
fatal error: mpi.h: No such file or directory
I know I did not give complete information but I can tell more if needed. How can I make the Petsc to know where is mpi.h?
Typically, you should use mpicc (or mpicxx for C++) to compile instead of gcc (or g++ for C++). These commands are simple wrappers around gcc and g++ that simply add in the appropriate -I/path/to/mpi/includes and -L/path/to/mpi/libs automatically and should be included with your openmpi install. In the absence of that, simply add -I/path/to/mpi/includes in your command to compile the appropriate files. This tells the compiler where to look for the appropriate header files.
To answer the question. To prevent a C/C++ editor from showing errors as you tyoe in the "special code" just use:
#include </usr/include/mpi/mpi.h>
which seems to be a link -- but doing that turns off the errors in Netbeans editor so I can code without distraction.
Note: Using Ubuntu 18.04 Desktop as editing machine -- and testing run machine -- but I compile manually using mpic as noted previously.
sudo mpicc c_pi.c -o c_pi
and then...
mpiexec ./c_pi
hth
I know how to use g++ and all that to compile c++ programs.
My question is, if I have some code which depends on various libraries, how can I compile it into a simple executable that I can send anyone. For this I would be happy with just keeping it on os x.
I would like to know how to compile a "real" program not just an executable I can run locally.
I have tried googling this but haven't found much.
Do I have to use installing software?
I know in windows you can make some simple .exe stuff that use common DLL files.
You a looking for "static linking". That will import all the needed code from the libraries into your executable. Note the executable will get larger. If you are using standard libraries, they should be present on standard OS installation.
You should try "-static" flag of g++.
Running "ldd your_executable_name" should display all libraries your executable uses (linked dynamically).
Since you are talking about Mac OS X, you probably want to make a bundle. Qt Software has a very useful deployment guide for getting started with this kind of activity.
You can use -static or -s option for static linking in gcc or g++