Missing dll's when compiling c++ programs using mingw compiler in cygwin - c++

When I compile my c++ programs in cygwin with the mingw compiler, the resulting executables don't run because they're missing the following dll's:
libstdc++-6.dll
libgcc_s_seh-1.dll
libwinpthread-1.dll
An example of a compilation command:
$ x86_64-w64-mingw32-g++ -Wall deque.cc -o deque
I've tried adding the following linker options as well:
-static -static-libgcc -static-libstdc++
But they don't seem to be helping either.
I went looking through my dll's at:
C:\cygwin\lib\gcc\x86_64-w64-mingw32\5.4.0
But couldn't find the dll's there. Is it possible I just don't have these dll's on my computer? If so, where would I get them?
I understand there are other similar questions on stackoverflow, but looking through them I couldn't find any solid answers to this variation of the question.

Use https://cygwin.com/packages/ to search the contents of cygwin packages.
As reported by
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmingw64-x86_64-gcc-g%2B%2B%2Fmingw64-x86_64-gcc-g%2B%2B-5.4.0-3&grep=libstdc%2B%2B-6.dll
usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
same for
usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_seh-1.dll
usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll

I´ve had the same problem when compiling.
I decided to make a new instalation of cygwin, I followed instructions for a fresh instalation of cygwin from:
https://gist.github.com/patrickmoffitt/30684ec23fe82eabe0e3609cab2425b2
(in the point 6) using the package manager, selected the packages to install.... but in my case I also needed to install:
make
gdb
https://www.jetbrains.com/help/clion/quick-tutorial-on-configuring-clion-on-windows.html#Cygwin
At this point, when finish my new instalation, i added in the enviroment variables this route:
C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\bin
(this route is where the .dll are)
This worked for me, hope this could help.
Another solution is, copying all the required .dll (form the path I mentioned) and pasting them where the .exe is. Do this every time is a bit annoying.

Related

Cant compile c++ on OS X Big Sur, "ld: library not found for -lgcc_s.10.4"

After upgrading my MacBook Pro to OS X 11.1 Big Sur, I am unable to get compilation of c++ programs using gcc to work.
I am using CLion with CMake, and I get the following error when reloading the CMake configuration
ld: library not found for -lgcc_s.10.4
The things that I have tried are installing Xcode, it installed without error.
I have tried to create a symlink as suggested here https://github.com/Paxa/fast_excel/issues/33
$ cd /usr/local/lib
$ sudo ln -s ../../lib/libSystem.B.dylib libgcc_s.10.4.dylib
It appears that the library libSystem.B.dylib is not present. Some sites mention that the libraries starting with Big Sur reside in some "shared cache", which I have no idea of what it is and how to access it, let alone make ld access it on its own.
Any suggestions on how to solve this are very welcome. Thank you!
According to this answer you should use: g++-10 -o main main.cpp
The correct path of brew installed g++ in MacOS is:
$ which g++-10
> /usr/local/bin/g++-10
--
$ which g++
> /usr/bin/g++ //this is alias of clang (same for lyb)
If you use CMakeLists.txt file you will configure it like this:
set(CMAKE_CXX_COMPILER "/usr/local/bin/g++-10" CACHE STRING "C compiler" FORCE)
set(CMAKE_C_COMPILER "/usr/local/bin/gcc-10" CACHE STRING "C++ compiler" FORCE)
set(CMAKE_CXX_STANDARD 17)
In general, gcc tends not to work on more recent versions of Mac OS. The solution is to use the build in C/C++ compilers. To automatically use these, instead of GCC, set these environment variables:
CC="clang"
CXX="clang++"
This will use the built in Mac compilers. Once doing this, I have yet to run into an issue with compiling that wasn't due to the actual code being compiled.
Thank you for all the answers highlighting different things that could solve the issue. What ended up working was to run brew reinstall gcc, and pointing CLion (or plainly CMake as Mike mentioned) to use the correct compiler (something that I had already done, but I want to mention it here if anyone else finds this question and has the same problem), the paths that I use are
/usr/local/Cellar/gcc/10.2.0/bin/gcc-10
/usr/local/Cellar/gcc/10.2.0/bin/g++-10
These paths are actually just the explicit locations that are linked from
/usr/local/bin/g++-10
/usr/local/bin/gcc-10
Also, as Matt Braunstein mentioned, it is possible to use clang that is supplied with Mac OS X, something I did while figuring out how to solve my issues with gcc.
My thoughts on the problem is that somehow, installing gcc with homebrew didnt install everything needed as it appeared to already be installed from a previous version, the reinstall command seemed to rectify this.
Again, thank you for the answers that helped me find this solution, and possible workarounds.
I spent hours trying to solve this compilation problem with cmake, the original statement in CMakeLists.txt for library linkage is!
link_directories(/usr/local/lib)
target_link_libraries(Program libsndfile.dylib)
With error message after make:
ld: library not found for -lsndfile
The solution that works is to add the entire path like this:
target_link_libraries(Program /usr/local/lib/libsndfile.dylib)
There is no need to have this in Ubuntu, but somehow the new MacOS requires it.

How to compile Quantlib via Xcode?

I am trying to install QuantLib on my Mac running OSX 10.11.6. Installed Boost 1.59 via MacPorts and then followed these instructions.
I used these additional environment variables
./configure --with-boost-include=/opt/local/include/ \
--with-boost-lib=/opt/local/lib/ --prefix=/opt/local/ \
CXXFLAGS='-O2 -stdlib=libstdc++ -mmacosx-version-min=10.6' \
LDFLAGS='-stdlib=libstdc++ -mmacosx-version-min=10.6'
and then make && sudo make install.
However when I run the Bermuda Swaption test it gave me the same error described here.
Little premise: I don't know anything about C++. I need QuantLib to work on Python. So I read carefully the answer by SmallChess and tried to solve it by myself. As I read in his answer
You can't just compile BermudanSwaption.cpp and hope everything would be fine. You have to compile the entire QuantLib library and link with the generated library files. Please google "compiling and linking C++" for more information.
By far, the easiest way to make it happen on Mac is to do it with Xcode. You will need to create a new Xcode project, and import the entire Quantlib project files into it. Next, you will need to create a main() function. Xcode does the compiling and linking for your automatically.
This is what I exactly did:
created a new project in Xcode (version 8.2.1)(file/new project/Command Line Tool/"HelloWorld"/Documents/create)
selected Targets, Build Phases and Link Binary With Library. Added libQuantLib.0.dylib
set libstdc++(GNUC++ standard library) as C++ Standard Library in Build Settings
Modified Header Search Paths to include: /opt/local/include/, and Library Search Paths to include: /opt/local/lib
C++ Language Dialect is set on Compiler Default.
Dragged the ql folder onto the left window of the Xcode
Now, I managed to copy a simple code which includes the library and even if there are many warnings, it runs. Still when I run on the Terminal the command for the Bermuda Swaption test I get the same error. What am I doing wrong?
Additional info (may or may not be useful): if I change the C++ Standard Library setting on Xcode to libc++, I get on Xcode the same error I get when i try the Bermuda Swaption test (ld: symbol(s) not found for architecture x86_64).
Any help would be very much appreciated
Regards
EDIT: you can find a picture of the code at https://i.stack.imgur.com/1zhjO.png

Compiling error libgcc_s_dw2-1.dll missing nothing works

I've found exactly the same topics on stackoverflow, unfortunately none of the solutions presented in similar topics actually worked in my case.
I'm using latest version of CodeLite 7 + MinGW, the problem I got is that everytime I want to compile c++ project I get the following message:
The program can't start because libgcc_s_dw2-1.dll is missing.
Problem known, but frankly nothing works in my case:
1) I did try to swap this file from CodeBlocks \bin directory - didn't work.
2) I did try to update MinGW libraries - didn't work.
3) I did try to add -static in linker options in CodeLite - didn't work
4) Set environmental path to C:\MinGW\bin - didn't work either
5) Download libgcc_s_dw2-1.dll from the Internet, swapped it - didn't work.
Maybe I'm missing something but I don't know how to handle it on my own.
Perhaps I might be doing something wrong with codelite build setting, can you please help me out with this ?
Go to C:/mingw/bin copy all dll files(it would be easy if u sort by type) and paste it in the codelite folder and you are done.
add the following in the project setting linker option:
-static-libgcc -static-libstdc++

MinGW "undefined reference to IMG_Load/IMG_Init/IMG_Quit" LazyFoo

I am going off of LazyFoo's SDL2 tutorials for C++ using the MinGW g++ compiler (using console). I have followed his page here, step-for-step. I have finally come across this error after having downloaded his example.
I have seen plenty of people online struggle with SDL_Image, but I've not yet seen this and I haven't found any solution to it yet.
I've loaded the include and lib folders with the proper assets
I've copied all necessary .dll's to my compile destination
The example LazyFoo provides includes for SDL_Image and SDL itself
(this question my sound redundant, but I've yet to come across a solution that applies to console-compilation)
Based on the comments above, the answer seems to be:
You need to install the development libraries for SDL_image.
You can download them here: https://www.libsdl.org/projects/SDL_image/
(look under the heading "Development libraries").
You need to ensure the path where the libSDL2_image.a file resides is in the linker search path. One way of doing this is to add an appropriate -L parameter to the link command. You could also drop the file in the default library search path.
I've had this problem in linux. the solution is simple.
add to linker:
-lSDL2_image -g `sdl2-config --cflags --libs`
I had the same problem, and the solution was to include the SDL2main library in linker parameters.
For Dev-C++ IDE you can follow the instructions below:
Get SDL or SDL2 working correctly with Dev-C++

Why am I getting a procedure entry point error for this simple C++ code?

I'm writing an SFML game and when I try to run the code this is the error I get:
The procedure entry point _gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll
I've linked to all the libraries correctly and the include files are correct. I've even tried what other answers suggested by putting the libstdc++-6.dll inside the directory of my exectable but still nothing.
Another answer said to put the MinGW/bin directory before any other directory in the PATH environment variable, which I did as well and it still didn't work.
Note: I get this error only when I try to use SFML code. It runs successfully when I comment it out.
OK, the note you added tells me that the SFML stuff was compiled with another compiler version/configuration, newer one if memory serves right.
You need to make sure that SFML and your code are compiled by the same compiler (versions/configuration) or at least compatible compiler (versions/configuration).
I see that the latest binary packages of SFML use GCC 4.7, and the latest Code::Blocks (mingw) comes with the TDM GCC 4.7 build, so it might be enough to upgrade Code::Blocks and make sure you use the SFML GCC 4.7 TDM (SJLJ) package (and use the gcc that comes with Code::Blocks, of course).
Otherwise, you should probably install the TDM-GCC 4.7 compiler build manually, or if nothing works, compile SFML yourself.
This is just a PATH ordering issue.
Most likely you'll have multiple libstdc++-6.dll files loaded in your path. You can check by running where libstdc++-6.dll in your command prompt.
What you do is to make sure your MinGW bin folder is loaded before everything else. Try moving it to the first one in your global PATH.