Discussion :

[Caduchon]

Bonjour à tous,

Je possède un projet utilisant BLAS et LAPACK qui compile parfaitement sous Visual 2000, mais à l'heure de le compiler avec Visual 2010, un problème de link apparait. Par désespoir, je me suis finalement rabattu sur un exemple simple utilisant BLAS et LAPACK qui présente toujours la même erreur.

J'ai repris l'exemple qui est décrit ici :

Using LAPACK subroutines in a Visual Studio C/C++ Project without a FORTRAN compiler
Download the LAPACK precompiled binaries for MinGW. You should have a two files: liblapack.lib and liblapack.dll (libblas.lib libblas.dll if you also want the Reference BLAS) .
OPTIONAL: Obtain a tuned version of BLAS for your machine (refer to "Compiling GotoBLAS").
Create a Visual Studio project with the following sample C program:
For C++ program, rename the prototypes in the above program to
void dgesv_( )
void dgels_( )
to
extern "C" void dgesv_( )
extern "C" void dgels_( )
Add the the BLAS and LAPACK libraries to the Visual Studio project settings,
under Linker -> General -> Additional Library Directories: the directory where your liblapack.lib is.
under Linker -> Input -> Additional Dependencies: libblas.lib;liblapack.lib (For example, on my machine, I am using the Reference BLAS)
Note: because BLAS libraries commonly provide faster versions of some LAPACK subroutines, the BLAS library must be listed before before LAPACK library.
Note: make sure that all the dll (BLAS, LAPACK, MinGW dlls) are on your system path or copy them in the WINDOWS\system32 folder, else binary won't run.
Compile the project and run the resulting executable. You should get the output: The solution is -0.661082 9.456125 -16.014625

Cet exemple semble correct, mais ça ne fonctionne pourtant pas. J'obtiens le message suivant à la compilation, qui correspond parfaitement au message d'erreur de mon projet :

1> test.cpp
1>test.obj : error LNK2001: unresolved external symbol _dgesv
1>C:\Users\sainvitu\Documents\Visual Studio 2010\Projects\test\Release\test.exe : fatal error LNK1120: 1 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Mes librairies BLAS.lib et LAPACK.lib semblent correctement linkées et existent, car lorsque je change le nom de la librairie dans les options de link j'obtiens un message totalement différent spécifiant bien qu'il n'a pas pu trouver la librairie.
Je pense que le problème vient d'un ajout d'un underscore ( _ ) devant le nom de la fonction, et, étant très peu expérimenté avec Visual C++, je n'ai aucune idée de comment paramétrer cela.

Par ailleurs, je ne comprends pas très bien ce que vient faire Mingw ici ni comment l'utiliser. Est-il important pour la bonne compilation du projet ou n'est-ce qu'un contexte sans importance ?

Si quelqu'un sait comment me sortir de ce pétrin, ce serait vraiment très apprécié.
Merci d'avance,
Caduchon.

[bacelar]

Le contenu de votre citation fait plus penser à du bricolage cas une conception soignée.

On ne va pas se mettre à chasser le dahu ni à mettre des ronds dans des carrés.

Trêve de métaphore, utilisez les outils type DUMPBIN fourni avec VS sur vos lib.
Cela donnera le véritable nom décoré exporté par la lib.

Pour une vue succincte des conventions de nommage C et Fortran :
http://msdn.microsoft.com/en-us/libr...(v=vs.60).aspx

Cela permettra de savoir quel convention de nommage doit être appliqué et quelles modifications doivent être appliquées dans les fichiers d'en-tête (si le mode bricolage est la norme ), ou dans la configuration du projet VS si les implémenteurs ont fait correctement leur boulot pour l'interopérabilité?

Donc, c'est quoi le résultat de l'affichage des symboles de votre lib avec DUMPBIN ou consort ?