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 build cd 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
make make 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:
- 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
- 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.