我在Microsoft Windows（64位）上安装了MinGW和MSYS，目录C:MinGW （MSYS目录是C:MinGWmsys1.0 ）。 我从官方的ftp下载了最新的GNU科学图书馆（ GNU GSL ）包。
我已经使用MSYS来执行configure和成功，如在GSL包中的INSTALL文件中所述。 这意味着，在MSYS命令行界面中，在MSYS home目录中，我插入了：
$ ./configure $ make $ make install
这将生成MSYS目录（ C:MinGWmsys1.0 ）下的local目录，其中包括目录bin ， include ， lib和share 。
我已经成功编译了示例程序 （根据GSL手册中的说明，计算贝塞尔函数$ J_0（x）$在$ x = 5 $的值）
厨师10：如何使用remote_file或类似从Windows共享中获取文件？
通过一个dynamic的表单和面板循环，并检查单选button是否检查
QueryUnbiasedInterruptTime是单调的吗？
在Windows 8中更改默认磁贴的形状
$ gcc -Wall -I/usr/local/include -c example.c
这将导致一个对象文件example.o ，正如所料，没有任何错误消息。
$ gcc -L/usr/local/lib example.o -lgsl -lgslcblas -lm
这产生一个可执行的a.exe ，可以在MSYS环境中执行。 但是，在Windows命令行界面中， cmd.exe尝试运行可执行文件时出现以下错误消息：
程序无法启动，因为您的计算机缺lesslibgsl-0.dll。 尝试重新安装程序来解决这个问题。
我不知道什么是缺less的？ 应该怎么做才能生成可执行文件？
我可以运行在具有JRE 1.6的系统上使用Java 1.8构build的应用程序吗？
从AutoCompleteStringCollection删除重复c＃
Windows窗体转换为HTML
Path.equals（）在Windows 10上为两个不同的文件夹（小写m和大写M）返回true
当您为MinGW生成项目时，在MSYS下，应始终为./configure指定一个--prefix参数。 （ /usr/local默认指定一个MSYS特定的路径，这完全不适用于MinGW应用程序的开发）。 在你的情况下，你应该这样配置GSL：
./configure --prefix=C:/MinGW
或者更好的是，从源文件中分离构建文件（例如，作为GSL顶级源目录的子目录）：
mkdir build cd build ../configure --prefix=C:/MinGW
这确保了在MSYS之外运行时，由程序包安装的所有库和头文件都位于MinGW可以找到它们的适当目录中，更重要的是，安装的DLL通过%PATH%搜索找到。
通过像以前那样进行配置，随后运行
make make install
你已经安装了MinGW库和头文件供MSYS使用（这是错误的），特别是libgsl-0.dll将被安装到C:/MinGW/msys/1.0/local/bin ，而它应该在C:/MinGW/bin （这是后一个命令将安装它的地方，在配置了相应的--prefix=C:/MinGW规格后）。
重要脚注
您应该注意，上述过程将正确地准备GSL（或以类似方式准备的任何其他库），以便与MinGW一起使用，并允许您在开发主机上运行与此类库链接的应用程序（或在具有类似MinGW安装的任何其他主机上）。 但是，如果您希望分发这些应用程序（并且提供您遵守任何许可条件），以便它们可以作为独立应用程序运行（即，不要求将MinGW安装在最终用户的机器上），那么您必须小心运行时间依赖性将在您的分配中得到正确满足。 要做到这一点，您必须选择：
静态链接应用程序。 如果您的发行版仅限于一个，或者两个可执行文件，但这样做可能是适当的，但在可分发的应用程序套件中，随着具有公共核心库依赖项的可执行文件数量的增加，这将很快导致“可执行文件膨胀”。 在后一种情况下，更好的选择是
动态链接应用程序，并分发任何必需的DLL（系统DLL除外）以及应用程序套件的副本; 在这种情况下，您不应该对最终用户的机器上可能适用或不适用的目录布局或%PATH%设置做任何假设; 你应该简单地打包你的发行版，以便所有提供的可执行文件及其附带的DLL将被安装到一个相同的目录中。
我也发现一个部分的解决方案; 但我不知道为什么它的工作原理！
使用与我在本文中提到的相同的过程和配置，如果使用Windows cmd （CLI），并且将C代码（ example.c ）编译并链接到
gcc -c example.c -I"C:MinGWmsys1.0localinclude" -Wall gcc -static example.o -L"C:MinGWmsys1.0locallib" -lgsl -lgslcblas -lm
g++ -c example.cpp -I"C:MinGWmsys1.0localinclude" -Wall g++ -static example.o -L"C:MinGWmsys1.0locallib" -lgsl -lgslcblas -lm
即在链接中使用-static选项，那么一切正常，最终的可执行文件运行没有任何错误消息。 所以，问题似乎与动态链接库有关。
如果我错了，请纠正我。
可执行文件不会在Windows cmd下运行，因为您编译的库libgsl-0.dll不在系统或用户路径中。 Windows不知道在哪里寻找它。 直接的解决办法是通过编辑环境变量PATH来包含libgsl-0.dll的位置来告诉系统在哪里找到它。 这可以通过输入cmd来完成
PATH=PATH;path-to-libgsl-0.dll
在命令行上。 （我并不完全记得库在哪里，所以请原谅我不具体。）这只会持续到会议，而要永久更改必须通过控制面板编辑PATH变量。 访问环境变量的一种方法是通过单击窗口左侧的“高级系统设置”（通过点击控制面板 – >系统和安全 – >系统）或右键单击计算机的开始菜单并选择属性。 点击“高级系统设置”打开一个窗口，其中显示“环境变量”按钮，通过单击该按钮可以访问环境变量。 但是，为了编辑PATH，我建议使用可以在这里找到的免费软件工具“PathEditor.exe”。 这个实用程序使得这个过程更容易。
不过，您的构建设置还不够理想。 在没有任何选项的情况下使用.configure步骤意味着生成的文件将被安装在C： MinGW msys 1.0 local下并分布在多个目录中。 在安装了其他开发库之后，如果您想要安装更新版本的GSL，将很难删除这些文件。 我建议在.configure步骤中添加--prefix=C:/MinGW/gsl选项。 （对于一组完整的选项运行.configure --help 。如果需要，可以非常容易地安装，只需删除或重命名C： MinGW gsl即可。 此外，MSYS的目的是促进GNU系统的软件构建，而不是Windows方式。 一旦建立的软件不应该驻留在MSYS下，而是在C： MinGW下的某个地方，并且可以使用C： MinGW bin中的构建工具访问这些工具，这些工具用于使用cmd或其他合适的Windows工具构建本机Windows程序。 实际上，这意味着如果需要使用MSYS来构建在MinGW中使用的软件（比如GSL头文件和库），则应始终使用--prefix=C:/MinGW 。 尽管如此，由于给出的原因，选择--prefix=C:/MinGW/software 。
一旦安装软件，不要忘记编辑PATH，以便系统可以找到任何所需的库。
这并不简单。 gcc从bash shell中的LINUX命令提示符运行。 MinGW32-gcc从cmd.exe shell中的DOS命令提示符处运行。 执行需要动态链接库（DOS中的.dll或Linux中的.so.la）的程序所需的动态链接也取决于操作系统。 Linux动态库和Windows动态库不可互换。 这是预料之中的; 但是，在Linux的bash shell中由gcc和ld创建的静态库似乎与Windows的cmd.exe shell中的MinGW32-gcc不兼容，这让我感到惊讶。 我不能让MinGW32-gcc链接到libgsl.a; 我不断从ld得到未解决的引用。 我也无法弄清楚如何让GSL在cmd.exe外壳中构建。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
