[Mingw-users] _imp__ prefixes when linking

241 views
Skip to first unread message

Christoph Groth

unread,
Mar 19, 2012, 11:03:49 AM3/19/12
to mingw...@lists.sourceforge.net
Hello,

We are experiencing a problem while trying to link a library compiled
with MinGW: We need to link against the LAPACK and BLAS libraries and
this works without problems on unix-like platforms. With MinGW,
however, we get many errors like this:

"undefined reference to '_imp__strevc_'"

"strevc" is a LAPACK routine which should be present in one of the
libraries we link against.

These errors appear in two different cases:

(1) Trying to link against libraries downloaded from
http://www.scipy.org/Installing_SciPy/Windows#head-cd37d819e333227e327079e4c2a2298daf625624

(2) Trying to link against BLAS and LAPACK compiled with MinGW on the
same machine. (This has been tried by a colleague and not myself.)

I understand that the _imp__ prefix is normally used for functions which
are present in a small static library. The _imp__ functions then call
the real routines in a DLL.

However, in case (1), there is no DLL but only large static libraries.

Thank you in advance for suggestions on how to deal with this problem.
Can someone perhaps even recommend the best way to use LAPACK/BLAS under
Windows with MinGW? (Compile it from source? Use binaries? Which?)

Christoph


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
MinGW-users mailing list
MinGW...@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-use...@lists.sourceforge.net?subject=unsubscribe

Eli Zaretskii

unread,
Mar 19, 2012, 1:33:48 PM3/19/12
to MinGW Users List
> From: Christoph Groth <c...@falma.de>
> Date: Mon, 19 Mar 2012 16:03:49 +0100

>
> We are experiencing a problem while trying to link a library compiled
> with MinGW: We need to link against the LAPACK and BLAS libraries and
> this works without problems on unix-like platforms. With MinGW,
> however, we get many errors like this:
>
> "undefined reference to '_imp__strevc_'"
>
> "strevc" is a LAPACK routine which should be present in one of the
> libraries we link against.
>
> These errors appear in two different cases:
>
> (1) Trying to link against libraries downloaded from
> http://www.scipy.org/Installing_SciPy/Windows#head-cd37d819e333227e327079e4c2a2298daf625624
>
> (2) Trying to link against BLAS and LAPACK compiled with MinGW on the
> same machine. (This has been tried by a colleague and not myself.)
>
> I understand that the _imp__ prefix is normally used for functions which
> are present in a small static library. The _imp__ functions then call
> the real routines in a DLL.
>
> However, in case (1), there is no DLL but only large static libraries.

Could it be that these functions are declared on some header as
`__declspec(dllimport)', or maybe some compiler switch made them be
declared like this? If so, I think the linker will insist on linking
against a DLL. If you don't have a DLL, removing those declarations
should set you up.

Earnie Boyd

unread,
Mar 19, 2012, 1:39:11 PM3/19/12
to MinGW Users List
On Mon, Mar 19, 2012 at 1:33 PM, Eli Zaretskii <el...@gnu.org> wrote:
>> From: Christoph Groth <c...@falma.de>
>> Date: Mon, 19 Mar 2012 16:03:49 +0100
>>
>> We are experiencing a problem while trying to link a library compiled
>> with MinGW: We need to link against the LAPACK and BLAS libraries and
>> this works without problems on unix-like platforms.  With MinGW,
>> however, we get many errors like this:
>>
>> "undefined reference to '_imp__strevc_'"
>>
>> "strevc" is a LAPACK routine which should be present in one of the
>> libraries we link against.
>>
>> These errors appear in two different cases:
>>
>> (1) Trying to link against libraries downloaded from
>>     http://www.scipy.org/Installing_SciPy/Windows#head-cd37d819e333227e327079e4c2a2298daf625624
>>
>> (2) Trying to link against BLAS and LAPACK compiled with MinGW on the
>>     same machine.  (This has been tried by a colleague and not myself.)
>>
>> I understand that the _imp__ prefix is normally used for functions which
>> are present in a small static library.  The _imp__ functions then call
>> the real routines in a DLL.
>>
>> However, in case (1), there is no DLL but only large static libraries.
>
> Could it be that these functions are declared on some header as
> `__declspec(dllimport)', or maybe some compiler switch made them be
> declared like this?  If so, I think the linker will insist on linking
> against a DLL.  If you don't have a DLL, removing those declarations
> should set you up.
>

Or do you just need to use the -static switch to GCC?

--
Earnie
-- https://sites.google.com/site/earnieboyd

Mikko Lyly

unread,
Mar 19, 2012, 3:54:29 PM3/19/12
to MinGW Users List

1) Both BLAS and LAPACK 3.4.0 should compile with MinGW out of the box:

tar xvfz lapack-3.4.0.tgz
cd lapack-3.4.0
cp make.inc.example make.inc
cd BLAS/SRC/
make
cd ../..
make

This should produce two static libs: librefblas.a and liblapack.a

If the reference implementation of BLAS is not fast enough for your
purposes,
you might consider replacing it e.g. with ATLAS (not worth the trouble in
most
cases, imho).

2) The error message "undefined reference to '_imp__strevc_'" is most
probably
due to the presence of __declspec(import) attribute in front of the
prototype of
strevc() in one of your project header files, as already pointed out by Eli
Zaretskii.

If so, you can just remove that attribute when linking against the static
libraries.

Another possibility is to create a dll from the static libs. The link you
provided
explains how to do this with gcc. The following modified line works with
librefblas.a
and liblapack.a, producing the combined import library blaslapack.lib and
dynamic lib
blaslapacl.dll:

gcc -shared -o blaslapack.dll -Wl,--out-implib=blaslapack.lib
-Wl,--export-all-symbols
-Wl,--allow-multiple-definition -Wl,--enable-auto-import -Wl,--whole-archive
liblapack.a
librefblas.a -Wl,--no-whole-archive -lgfortran

Now, link your application against blaslapack.lib and put blaslapack.dll
somewhere in PATH.

ML

Reply all
Reply to author
Forward
0 new messages