À l'aide de Bibliothèque Scientifique GNU (GSL) sous x64 de Windows avec MinGW

J'ai installé MinGW et MSYS sur Microsoft Windows (64 bits), à l'intérieur du répertoire C:\MinGW (MSYS répertoire est C:\MinGW\msys\1.0). J'ai téléchargé la dernière version de GNU Scientific Library (GNU GSL) package à partir de la ftp officiel.

J'ai utilisé MSYS pour effectuer configure et make avec succès, comme décrit dans la INSTALL fichier dans le GSL paquet. Cela signifie que, dans le MSYS interface de ligne de commande, dans le MSYS home répertoire, j'ai inséré:

$ ./configure
$ make
$ make install

Cela produit un local répertoire sous le MSYS répertoire ( C:\MinGW\msys\1.0 ), y compris les répertoires bin, include, lib, et share.

J'ai compilé avec succès le exemple de programme (qui calcule la valeur de la fonction de Bessel $J_0 (x)$ en $x = 5$), selon les instructions dans le GSL manuel, par

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

Présente les résultats dans un fichier objet example.o, comme prévu, sans aucun message d'erreur.

Le fichier objet est lié, selon le instructions par

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

Ce qui produit un exécutable a.exe qui peut être exécutée dans le MSYS de l'environnement.
Cependant, dans un Windows interface de ligne de commande, cmd.exe, en essayant d'exécuter le fichier exécutable donne le message d'erreur suivant:

Le programme ne peut pas démarrer car libgsl-0.dll est absent de votre ordinateur. Essayer de réinstaller le programme pour corriger ce problème.

Je me demande ce qui est absent? Que doit-on faire pour produire le fichier exécutable?

OriginalL'auteur AlQuemist | 2015-05-03

  1. 7

    Lorsque vous construire des projets pour MinGW, en vertu de MSYS, vous devriez toujours spécifier un --prefix argument ./configure; (le /usr/local par défaut spécifie un MSYS chemin d'accès spécifique, ce qui est totalement inadaptées pour MinGW le développement de l'application). Dans votre cas, vous devez avoir configuré GSL donc:

    ./configure --prefix=C:/MinGW

    ou, mieux encore, de séparer les fichiers de compilation à partir des sources, (par exemple un sous-répertoire de la GSL haut répertoire source):

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

    Cela garantit que toutes les bibliothèques et en-têtes installés par le paquet sont situés dans les répertoires appropriés, où MinGW pouvez les trouver, et plus important encore, où est installé les Dll sont trouvés par un %PATH% de recherche, lors de l'exécution à l'extérieur de MSYS.

    Par la configuration que vous avez fait, quand vous avez par la suite couru

    make
make install

    vous avez installé MinGW bibliothèques et en-têtes pour une utilisation par MSYS, (ce qui est faux), et en particulier libgsl-0.dll ont été installés dans C:/MinGW/msys/1.0/local/bin, alors qu'il devrait être dans C:/MinGW/bin, (qui est l'endroit où la dernière commande serait installé, la configuration suivante avec le --prefix=C:/MinGW spécification).

    Importante Note De Bas De Page

    Vous devriez noter que la procédure précédente correctement préparer GSL (ou de toute autre bibliothèque préparé de la même manière), pour utilisation avec MinGW, et vous permettra d'exécuter les applications que vous avez lié avec ces bibliothèques sur le développement de votre hôte, (ou sur un autre hôte avec un analogue d'installation de MinGW). Cependant, si vous souhaitez distribuer ces demandes, (et à condition de respecter toutes les conditions d'octroi de licences), de sorte qu'ils peuvent être exécutés que la libre-debout applications, (c'est à dire sans une exigence que MinGW être installée à l'extrémité de l'utilisateur de la machine), vous doit prendre soin que de l'exécution des dépendances être satisfait de votre distribution. Pour ce faire, vous devez choisir soit:

    1. Lien de l'application statiquement. Cela peut être le cas, si votre distribution est limitée à un seul, ou peut-être deux exécutables, mais va rapidement conduire à "exécutable gonfler" le nombre de fichiers exécutables avec un tronc commun de la bibliothèque de la dépendance augmente, au sein d'une application de distribuer de la suite. Dans ce dernier cas, le meilleur choix serait de
    2. Lien de l'application dynamiquement, et de distribuer des copies de toutes les Dll nécessaires, (autres que les Dll système), ainsi que l'application de la suite; dans ce cas, vous devez faire aucune hypothèse quant à la disposition des répertoires ou %PATH% paramètres qui peuvent ou peuvent ne pas s'appliquer à l'extrémité de l'utilisateur de la machine; il vous suffit de paquet de votre distribution, tels que la livraison de tous les exécutables et leur accompagnement Dll sera installé dans un seul et même répertoire.
    Merci pour la réponse détaillée, @Keith Marshall. Avec votre suggestion de configuration, je peux maintenant compiler facilement dans Windows cmd, avec g++ -c example.c -o example.o et puis, lien avec g++ example.o -lgsl -lgslcblas -lm. Aucun message d'erreur n'apparaît.

    OriginalL'auteur Keith Marshall

  2. 1

    J'ai trouvé aussi une solution partielle; mais je ne sais pas exactement pourquoi ça marche!

    Avec le même procédure de configuration et dont j'ai parlé à l'origine dans la question, si on utilise Windows cmd (CLI) et on compile et liens le code C (example.c) avec

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

    ou d'un code C++ (équivalent à example.c) avec

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

    c'est à dire, à l'aide de la -static option dans la liaison, puis tout fonctionne parfaitement et le dernier exécutable s'exécute sans aucun message d'erreur. Donc, il semble que le problème a à voir avec dynamique reliant des bibliothèques.

    S'il vous plaît corrigez-moi si je me trompe.

    Cela fonctionne, après un effet de mode, en atténuant les symptômes du problème, plutôt que de s'attaquer à ses cause; en tant que tel, il est plus d'un (fondamentalement insatisfaisant), que d'une réelle solution.
    Pour clarifier: le problème fondamental de la cause, c'est que les bibliothèques et en-têtes ont été installés dans un endroit inapproprié. Cela donne lieu à la les symptômes que ces bibliothèques et en-têtes sont moins faciles à trouver au moment de la construction, et que les objets partagés (Dll) ne se trouvent pas au moment de l'exécution.Vous atténué le premier symptôme par la spécification explicite -I path/to/headers et -L path/to/libraries au moment de la construction. Vous atténué la deuxième en les reliant de manière statique, donc il n'y a pas de DLL de dépendance au moment de l'exécution, mais votre exécutable est devenu inutilement gonflé comme un résultat.
    Comme une dernière précision: le problème, c'est pas tellement avec la liaison dynamique aussi simplement que vous pouvez atténuer le symptôme du problème fondamental au moment de la construction, mais, si vous continuez à se lier dynamiquement, vous ne pouvez pas atténuer le placement de la condition de la DLL dans un répertoire où aucun natif (MinGW) application devrait jamais regarder pour elle; vous pouvez correct, par l'installation d'un préfixe approprié, comme C:/MinGW, alors que /usr/local (normal GNU package par défaut) est inapproprié pour MinGW construit des applications et de leurs bibliothèques.

    OriginalL'auteur AlQuemist

  3. 0

    L'exécutable ne fonctionne pas sous windows cmd parce que la bibliothèque
    libgsl-0.dll vous avez compilé n'est pas sur le système ou le chemin d'accès utilisateur. Windows ne
    ne pas savoir où chercher. La solution immédiate est-à-dire le système de
    où le trouver en modifiant la variable d'environnement PATH pour inclure le
    emplacement de libgsl-0.dll. Cela peut être fait en utilisant cmd en entrant

    PATH=PATH;path-to-libgsl-0.dll

    sur la ligne de commande. (Je n'ai pas vraiment souvenir d'où la bibliothèque serpente jusqu'alors
    s'il vous plaît pardonnez-moi pour ne pas être précis.) Cela ne durera la session,
    cependant, et pour rendre la modification permanente il faut modifier la variable de CHEMIN d'accès par
    en passant par le Panneau de Contrôle. Une façon d'accéder aux variables d'environnement
    en cliquant sur "paramètres système Avancés", qui se trouve à gauche dans
    la fenêtre résultant en cliquant sur Panneau de configuration->Système et Sécurité
    ->Système ou par un clic-droit sur Ordinateur dans le Menu Démarrer et en sélectionnant
    Les propriétés. En cliquant sur "paramètres système Avancés" ouvre une fenêtre où l'
    bouton "Variables d'Environnement" s'affiche et les variables d'environnement deviennent
    accessible en cliquant sur ce bouton. Pour modifier le CHEMIN d'accès, même si, je le ferais
    vous recommandons d'utiliser l'utilitaire freeware "PathEditor.exe" ce qui peut être trouvé ici. Cet utilitaire rend le processus beaucoup plus facile.

    Votre construction de l'installation est loin d'être optimale. À l'aide de la
    .configure étape sans aucune option signifie que les fichiers générés
    être installé sous C:\MinGW\msys\1.0\local et s'étaler sur plusieurs
    les répertoires. Il sera difficile de supprimer les fichiers dans le cas où vous souhaitez installer
    une version plus récente de GSL après avoir installé
    aussi d'autres
    les bibliothèques de développement. Je recommande l'ajout de l'option --prefix=C:/MinGW/gsl
    à la .configure étape. (Pour un jeu complet d'options de .configure --help.)
    De ce fait, il est très facile d'obtenir de l'installation
    si besoin est, tout simplement par la suppression ou le changement de nom C:\MinGW\gsl.
    En outre, le but de MSYS est de faciliter la construction de logiciels ciblés
    pour les systèmes GNU qui n'est pas la façon dont Windows. Le logiciel une fois construit
    ne doit pas résider en vertu de MSYS, mais plutôt quelque part sous C:\MinGW et de fait
    accessible à l'
    construire des outils C:\MinGW\bin qui sont utilisés pour construire des programmes natifs Windows
    à l'aide de cmd ou d'autres outils Windows. Dans la pratique, cela signifie que
    --prefix=C:/MinGW doit toujours être utilisé si la pme est nécessaire pour
    logiciel de construction pour être utilisé dans MinGW comme dans ce cas, la GSL fichiers d'en-tête et
    des bibliothèques. De préférence, même si, pour les raisons indiquées choisir --prefix=C:/MinGW/software.

    Une fois le logiciel installé, n'oubliez pas de modifier le CHEMIN de sorte que le système
    pouvez trouver toutes les bibliothèques nécessaires.

    OriginalL'auteur gostal

  4. 0

    Il n'est pas simple. gcc s'exécute à partir d'une invite de commande LINUX dans un shell bash. MinGW32-gcc s'exécute à partir d'une invite de commande DOS dans un cmd.exe shell. La liaison dynamique nécessaire à l'exécution d'un programme qui a besoin d'une bibliothèque de liens dynamiques (.dll dans le DOS ou ..la sous Linux) est aussi OS dépendante. Linux bibliothèques dynamiques et Windows bibliothèques dynamiques ne sont pas interchangeables. Ce qui est prévu; cependant, les bibliothèques statiques créés par gcc et ld dans Linux shell bash semble être incompatible avec MinGW32-gcc sous Windows' cmd.exe shell et ce qui me surprend. Je ne peux pas obtenir MinGW32-gcc lien vers libgsl.un; je reçois des références non résolues de ld. Je ne peux pas comprendre comment obtenir GSL à construire dans le cmd.exe shell.

    OriginalL'auteur Byron