Using GNU Scientific Library (GSL) under Windows x64 with MinGW

When you build projects for MinGW, under MSYS, you should always specify a --prefix argument to ./configure; (the /usr/local default specifies an MSYS specific path, which is entirely unsuitable for MinGW application development). In your case, you should have configured GSL thus:

./configure --prefix=C:/MinGW

or, better still, segregate the build files from the sources, (e.g. as a subdirectory of the GSL top source directory):

mkdir buildcd build../configure --prefix=C:/MinGW

This ensures that all libraries and headers installed by the package are located in appropriate directories, where MinGW can find them, and more importantly, where installed DLLs are found by a %PATH% search, when running outside of MSYS.

By configuring as you did, when you subsequently ran

makemake install

you've installed MinGW libraries and headers for use by MSYS, (which is wrong), and in particular libgsl-0.dll will have been installed into C:/MinGW/msys/1.0/local/bin, whereas it should be in C:/MinGW/bin, (which is where the latter command would have installed it, following configuration with the appropriate --prefix=C:/MinGW specification).

Important Footnote

You should note that the preceding procedure will correctly prepare GSL, (or any other library prepared in similar fashion), for use with MinGW, and will allow you to run applications which you've linked with such libraries on your development host, (or on any other host with a similar MinGW installation). However, if you wish to distribute such applications, (and provided you comply with any licensing conditions), so that they may be run as free-standing applications, (i.e. without a requirement that MinGW be installed on the end user's machine), you must take care that run time dependencies will be properly satisfied in your distribution. To achieve this, you must choose either to:

1. Link the application statically. This may be appropriate, if your distribution is limited to one, or maybe two executables, but will quickly lead to "executable bloat" as the number of executables with a common core library dependency increases, within a distributable application suite. In the latter case, a better choice would be to
2. Link the application dynamically, and distribute copies of any necessary DLLs, (other than system DLLs), along with the application suite; in this case, you should make no assumptions regarding directory layout or %PATH% settings which may or may not apply on the end user's machine; you should simply package your distribution such that all delivered executables and their accompanying DLLs will be installed into one and the same directory.

For reference, let me note that all previous answers are outdated. For Win64, MinGW and MSYS have been replaced by the independent projects Mingw-w64 and MSys2. And it is no longer necessary to compile GSL on your own: Use the binaries from https://packages.msys2.org/package/mingw-w64-x86_64-gsl.

I found also a partial solution; yet I don't know exactly why it works!

With the same procedure and configuration which I mentioned originally in the question, if one uses Windows cmd (CLI) and one compiles and links the C code (example.c) with

gcc -c example.c -I"C:\MinGW\msys\1.0\local\include" -Wallgcc -static example.o -L"C:\MinGW\msys\1.0\local\lib" -lgsl -lgslcblas -lm

or a C++ code (equivalent to example.c) with

g++ -c example.cpp -I"C:\MinGW\msys\1.0\local\include" -Wallg++ -static example.o -L"C:\MinGW\msys\1.0\local\lib" -lgsl -lgslcblas -lm

i.e., using the -static option in linking, then everything works perfect and the final executable runs without any error messages. So, it seems the problem has to do with dynamic linking of libraries.

Please correct me if I am wrong.