Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

I have installed MinGW and MSYS on Microsoft Windows (64bit), inside directory C:\MinGW (MSYS directory is C:\MinGW\msys\1.0). I have downloaded the latest GNU Scientific Library (GNU GSL) package from the official ftp.

I have used MSYS to perform configure and make successfully as described in the INSTALL file in the GSL package. That means, in the MSYS command-line interface, in the MSYS home directory, I have inserted:

$ ./configure
$ make
$ make install

This produces a local directory under the MSYS directory (C:\MinGW\msys\1.0) including the directories bin, include, lib, and share.

I have successfully compiled the example program (which computes the value of the Bessel function $J_0 (x)$ at $x = 5$) according to the instructions in the GSL manual, by

$ gcc -Wall -I/usr/local/include -c example.c

This results in an object file example.o, as expected, without any error messages.

The object file is linked, according to the instructions by

$ gcc -L/usr/local/lib example.o -lgsl -lgslcblas -lm

This produces an executable a.exe which can be executed in the MSYS environment. However, in a Windows command-line interface, cmd.exe, trying to run the executable gives the following error message:

The program can't start because libgsl-0.dll is missing from your computer. Try reinstalling the program to fix this problem.

I wonder what is missing? What should one do to produce the executable file?

like image 326
AlQuemist Avatar asked May 03 '15 15:05

AlQuemist


People also ask

What is GSL used for?

The GNU Scientific Library (GSL) is a numerical library for C and C++ programmers. It is free software under the GNU General Public License. The library provides a wide range of mathematical routines such as random number generators, special functions and least-squares fitting.


1 Answers

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:

  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.
like image 174
Keith Marshall Avatar answered Oct 05 '22 05:10

Keith Marshall