MPIR MinGW installation - "undefined reference to '_imp____gmpz_init'

[highcal...@gmail.com]

Hi,

I have been trying to run a simple calculation with MPIR on my Windows 7 machines for several days now. My only sources so far are the manual from version 2.6.0 (since 2.7.0 would not load from the mpir site) and some Google search results. I managed to do the following via MinGW:

- run ./configure --disable-static --enable-shared
- make
- make check

On one of my machines, everything went through, on the other, almost, there was one error during "make check": "FAIL: t-io_raw.exe", but it then went on.
(Is this all and now I can start using it or is a step missing?...)
Now I want to compile the following program called "mytest.cpp" with gcc; I tried typing "g++ mytest.cpp -o mytest" :

//-----------------------------------------------
#include "mpir.h"
#include "gmp.h"
#include "gmp-impl.h"

using namespace std;

int main ()
{
    mpz_t z; 

    mpz_init(z);
   
    return (0);
}
//-----------------------------------------------

The answer from the MinGW command line was

"C:\Users\....\...\Local\Temp\ccD1pbG8.o:mytest.cpp:(.text+0x20): undefined reference to '_imp____gmpz_init' "

and some further lines with similar content.

The program sits in the top folder of MPIR (C:/MPIR/mpir-2.7.0/), I have added this folder to the Windows PATH environment variable.
I can see the mpir.h file in this folder...(?...)
What is missing? I read in the MPIR documentation chapter 3.1 that "All programs using MPIR must link against the 'libmpir' library..." I then tried to compile via

g++ mytest.cpp -lmpir -o mytest

which resulted in

"C:/mingw/bin/ld.exe: cannot find -lmpir"

Are the links to the mpz libraries missing (if so, do I have to use some -I flag? Or - where are they)?

My next question (once this works) would be how (if) I can use MPIR in C code being called by Matlab (via mex-files).
I am relatively new to C Programming and would appreciate any hints. Thanks.

[Bill Hart]

On 3 June 2015 at 14:12, <highcal...@gmail.com> wrote:

Hi,

I have been trying to run a simple calculation with MPIR on my Windows 7 machines for several days now. My only sources so far are the manual from version 2.6.0 (since 2.7.0 would not load from the mpir site) and some Google search results.

I am not having an issue accessing the manual for 2.7.0 from the website. Is this the file you are having trouble accessing?

 

I managed to do the following via MinGW:

- run ./configure --disable-static --enable-shared
- make
- make check

On one of my machines, everything went through, on the other, almost, there was one error during "make check": "FAIL: t-io_raw.exe", but it then went on.

Thanks for letting us know. Can you send us any log files in the directory tests/mpz on that machine, as well as the file config.log. We will look into the failure.

 

(Is this all and now I can start using it or is a step missing?...)

That's it. You are good to go.

 

Now I want to compile the following program called "mytest.cpp" with gcc; I tried typing "g++ mytest.cpp -o mytest" :

In general we are not able to provide assistance with using the gcc compiler and linker. For this, perhaps you can refer to one of the many websites about compiling and linking using gcc, since it is not at all specific to MPIR.

 

//-----------------------------------------------
#include "mpir.h"
#include "gmp.h"
#include "gmp-impl.h"

using namespace std;

int main ()
{
    mpz_t z; 

    mpz_init(z);
   
    return (0);
}
//-----------------------------------------------

The answer from the MinGW command line was

"C:\Users\....\...\Local\Temp\ccD1pbG8.o:mytest.cpp:(.text+0x20): undefined reference to '_imp____gmpz_init' "

I cannot make a guess based on this. It looks like it isn't linking against mpir. This could be for any number of reasons.

 

and some further lines with similar content.

The program sits in the top folder of MPIR (C:/MPIR/mpir-2.7.0/), I have added this folder to the Windows PATH environment variable.

Did you installed MPIR on your system (sudo make install)?

 

I can see the mpir.h file in this folder...(?...)
What is missing? I read in the MPIR documentation chapter 3.1 that "All programs using MPIR must link against the 'libmpir' library..." I then tried to compile via

g++ mytest.cpp -lmpir -o mytest

which resulted in

"C:/mingw/bin/ld.exe: cannot find -lmpir"

You have to tell it where to find MPIR, e.g. with gcc's -L option.

 

Are the links to the mpz libraries missing (if so, do I have to use some -I flag? Or - where are they)?

If you don't install MPIR, the library is located in the .libs directory of your MPIR source tree. (This is fairly standard for a lot of linux libraries.)

 

My next question (once this works) would be how (if) I can use MPIR in C code being called by Matlab (via mex-files).
I am relatively new to C Programming and would appreciate any hints. Thanks.

I personally don't have any experience with Matlab. You might get lucky and find someone else on the list able to answer your question.

But I would suggest calling the Matlab support hotline as they would better be able to support you (and you likely paid them a lot of money to do so).

Bill.

 

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.
To post to this group, send email to mpir-...@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[sisy...@optusnet.com.au]

From: Bill Hart

> In general we are not able to provide assistance with using the gcc
> compiler and linker. For this, perhaps you can refer to one of the many
> websites about compiling and linking using gcc, since it is not at all
> specific to MPIR.

He's trying to use g++, which is the C++ compiler.
Should his configure flags therefore have included "--enable-cxx" (or
something similar) ?

Cheers,
Rob

[Bill Hart]

I don't think that is necessary. He's only using the C functions in his attached code, rather than the C++ classes.

Bill.

[leif]

highcal...@gmail.com wrote:
> I managed to do the following via MinGW:
>
> - run ./configure --disable-static --enable-shared
> - make
> - make check
>

> (Is this all and now I can start using it or is a step missing?...)

You have to run 'make install' as well.

Depending on whether you want to /exclusively/ use MPIR (which is a
drop-in *replacement* of GMP) as opposed to having parallel, independent
installations of both GMP and MPIR, you might consider configuring MPIR
with '--enable-gmpcompat'.

Roughly speaking, the latter just creates aliases for the headers and
libraries, such that you don't have to modify code to switch between
MPIR and GMP, i.e., you can '#include <gmp.h>' and use '-lgmp'
regardless of whether you're actually using GMP or its fork, MPIR.

If you intend to use the C++ layer of GMP/MPIR, you also have to
configure with '--enable-cxx'. This is /not/ necessary if you just want
to use the C interface / library from within C++.

> Now I want to compile the following program called "mytest.cpp" with
> gcc; I tried typing "g++ mytest.cpp -o mytest" :
>
> //-----------------------------------------------
> #include "mpir.h"
> #include "gmp.h"
> #include "gmp-impl.h"
>
> using namespace std;
>
> int main ()
> {
> mpz_t z;
>
> mpz_init(z);
>
> return (0);
> }
> //-----------------------------------------------

You don't have to (and shouldn't) include both mpir.h and gmp.h, nor
gmp-impl.h. (It is sufficient to just include mpir.h, or, in case you
configured with '--enable-gmpcompat', just gmp.h.)

To link your program to the MPIR C library, you have to

g++ mytest.cpp -o mytest -lmpir

(Again, in case you configured MPIR with '--enable-gmpcompat', 'g++
mytest.cpp -o mytest -lgmp' also works.)


-leif

[sisy...@optusnet.com.au]

Yeah – that sounds feasible.

But I was wondering more about name mangling and decorations.

 

According to the gmp manual at

https://gmplib.org/manual/Headers-and-Libraries.html#Headers-and-Libraries

C++ builds need to link to “-lgmpxx –lgmp” but I don’t know how that translates to mpir. (With the OP’s configure args, no libgmpxx.a libgmpxx.dll.a would have been created.)

 

However, I don’t do C++ and I don’t do dynamic builds ... so I should probably just shut up .... which I shall.

 

Cheers,

Rob

 

From: Bill Hart

Sent: Wednesday, June 03, 2015 11:09 PM

To: mpir-devel

Subject: Re: [mpir-devel] MPIR MinGW installation - "undefined reference to '_imp____gmpz_init'

I don't think that is necessary. He's only using the C functions in his attached code, rather than the C++ classes.

 

Bill.

On 3 June 2015 at 15:04, <sisy...@optusnet.com.au> wrote:

From: Bill Hart

In general we are not able to provide assistance with using the gcc compiler and linker. For this, perhaps you can refer to one of the many websites about compiling and linking using gcc, since it is not at all specific to MPIR.

He's trying to use g++,  which is the C++ compiler.
Should his configure flags therefore have included "--enable-cxx" (or something similar) ?

Cheers,
Rob

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mailto:mpir-devel%2Bunsu...@googlegroups.com.

To post to this group, send email to mpir-...@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[leif]

sisy...@optusnet.com.au wrote:
> I was wondering more about name mangling and decorations.

The C headers declare GMP's / MPIR's C functions with 'extern "C"' if
__cplusplus is defined (i.e., when you're using them from C++ code),
such that their names don't get mangled.

> According to the gmp manual at
> https://gmplib.org/manual/Headers-and-Libraries.html#Headers-and-Libraries
> C++ builds need to link to “-lgmpxx –lgmp” but I don’t know how that
> translates to mpir.

'-lmpirxx -lmpir'.

Unless you configured with '--enable-gmpcompat'.

Still, as Bill said, this is only necessary if you really use the C++
interface of GMP/MPIR.


-leif

[highcal...@gmail.com]

Dear All,

Thanks so much for all of your quick tips. I have attached a 7z archive with the log files (please let me know if it does not work). 

I understood if the configure/make/make check commands went through fine, that then MPIR should be installed on the computer? This is what I did.

In addition I now also ran "make install", which performed fine, but did not help. 

Then I tried to add a flag "-I" or "-L" to the gcc command, such that I typed

gcc mytest.c -o mytest -lmpir -I/C:/MPIR/mpir-2.7.0/

upon which it again showed me 

"C:/mingw/ [...] /bin/ld.exe: cannot find -lmpir"

where "[...]" stands for some directory up-and-down-climbs inside the "minGW" directory. However, I am with the shell currently in the C:/MPIR/mpir-2.7.0/ directory. I tried the "-v" option, and it gave, among other information which indicated that it did not really leave the "MinGW" directory: 

#include "..." search starts here:
#include <...> search starts here:
c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include
c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../include
c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include-fixed
c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include
End of search list.

Thanks for any insights.

[highcal...@gmail.com]

Comments regarding also the other (remaining) issues:

Yes, the 2.7.0 documentation failed to load from here (Germany), now again.

I did not use "sudo" - it did not recognize this command ("not found") - what is it? For administrators? (One of my machines is administrated by a super user.) I just used "make install".
I tried also

gcc mytest.c -o mytest -lmpir -IC:/MPIR/mpir-2.7.0/ -LC:/MPIR/mpir-2.7.0

but still no improvement ("cannot find -lmpir").
In my top MPIR directory MPIR/mpir-2.7.0, there is an "mpir.h" file, a "libmpir.la" file, and in the .lib subdirectory various similarly named files, in particular, again "libmpir.la", then "libmpir.lai", "libmpir.dll.a" and more - but nowhere a file called "libmpir.a" . Is this the system as it should be?

I did, in any case, perform "make check" and "make install" without any errors... how do I check if the installation was successful?
Thank you.

On Wednesday, June 3, 2015 at 2:26:11 PM UTC+2, highcal...@gmail.com wrote:

[Bill Hart]

As I said, the libraries are normally in the .libs directory of your MPIR source tree, so you are passing the wrong directory location.

Also, I don't know if msys or whatever you are using, will recognize C: It's not a linux path. I didn't check this, but that is to my recollection. You should pass the linux path, not the Windows one.

However, if you did "make install", they will be in the default library location for your system (maybe /usr/local/lib or /usr/lib?), or in prefix, if you specified that. You should first find the actual library files that are built so that you know you are passing the right path. By "find" I mean find them in your Linux shell, not with Windows Explorer.

Thank you for the log files. They will be very helpful in tracking down the reason for the make check failure.

Bill.

[Bill Hart]

I had a look at the log files, and the reason t-io_raw failed is because it was unable to create a file to write to.

This might be due to a virus checker, disk full, not having administrator privileges, the Windows file system being overloaded, or a bug we aren't aware of.

I certainly don't see an obvious way to resolve or further track down the issue. We'll keep an eye on other build reports and see if the issue pops up again anywhere else.

Bill. 

[highcal...@gmail.com]

Ok, (*)
It seems like I fixed it. Summarizing, critical points were:
- the order of the gcc options matter: "-o mytest" needs to go to the end, and "-lname" before but after the "-Ldir";
- as Bill said, the path should have ".libs" at the end because this is where the libraries are (even if they do not need to be named libmpir.a)
- (at least in MinGW) the working format is c:/MPIR/mpir-2.7.0/.libs (thus absolute, also from /usr/local/ or other places)

What worked was for example:
$ gcc mytest.c  -Lc:/MPIR/mpir-2.7.0/.libs -lmpir -o mytest
$ gcc mytest.c  -Lc:/MPIR/mpir-2.7.0/.libs -lmpirdll -o mytest

Thanks Bill and everybody for helping and stimulating my search hunger. Good night.
(*)[Backstage: After hours and days of searches, scanning through forums, talking to list members and reading documentation, I found :)]

On Wednesday, June 3, 2015 at 2:26:11 PM UTC+2, highcal...@gmail.com wrote:

[Bill Hart]

I believe I found the cause of the mpir-2.7.0.pdf not loading. I just experienced this. I was only having the problem in Google Chrome, and only with my virus scanner (Avast) turned on.

I imagine the problem will eventually go away once they fix the virus scanner. But turning it off for 10 minutes and restarting Chrome fixed the problem for me.

Bill. 

On 3 June 2015 at 20:27, <highcal...@gmail.com> wrote:

[highcal...@gmail.com]

Dear All,

Now the doc mpir-2.7.0.pdf is loading (Firefox); turning off the virus scanner was not changing anything.

One further question: As I wrote, the gcc compilation now works fine for me; however, I would like to call it from Matlab using mex files, and there, the compiler complains that it does not see any ".lib" files (when compiling with "mex ... -lmpir" it looks for a file "libmpir.lib") . Neither do I see any in the MPIR directories.

Should such files be there after a successful installation? Or do I have to set build options differently? Thank you.

Details and settings:
Mex compile command (in Matlab command line):
"mex -IC:/MPIR/mpir-2.7.0/ -LC:/MPIR/mpir-2.7.0/.libs/ -LC:/MPIR/mpir-2.7.0/mpf/.libs -LC:/MPIR/mpir-2.7.0/printf/.libs mexlib.cpp myfile.cpp",
where mexlib.cpp is the mex-file (interface to c code) and myfile.cpp uses some basic mpir commands (init, set, clear). Both files are in C:/MPIR/mpir-2.7.0.
Compiler answer:
"myfile.obj : error LNK2019: unresolved external symbol __imp___gmpf_init referenced in function "void __cdecl myfile(double)" "

[Bill Hart]

On 19 June 2015 at 12:06, <highcal...@gmail.com> wrote:

Dear All,

Now the doc mpir-2.7.0.pdf is loading (Firefox); turning off the virus scanner was not changing anything.

One further question: As I wrote, the gcc compilation now works fine for me; however, I would like to call it from Matlab using mex files, and there, the compiler complains that it does not see any ".lib" files (when compiling with "mex ... -lmpir" it looks for a file "libmpir.lib") . Neither do I see any in the MPIR directories.

Should such files be there after a successful installation? Or do I have to set build options differently? Thank you.

No, the MPIR GCC build doesn't create these as they are not needed for MPIR when used with GCC. But there are third party tools available to create lib files if you need this.

Bill.

[Bill Hart]

In fact, according to section 2.5 of the documentation, the Microsoft lib tool has to be used to do this.

I don't know if this information is current or not.

Bill.

[Brian Gladman]

On 19/06/2015 11:06, highcal...@gmail.com wrote:
> Dear All,
>
> Now the doc mpir-2.7.0.pdf is loading (Firefox); turning off the virus
> scanner was not changing anything.
>
> One further question: As I wrote, the gcc compilation now works fine for
> me; however, I would like to call it from Matlab using mex files, and
> there, the compiler complains that it does not see any ".lib" files
> (when compiling with "mex ... -lmpir" it looks for a file "libmpir.lib")
> . Neither do I see any in the MPIR directories.
>
> Should such files be there after a successful installation?

No, they have to be built after MPIR has been installed.

They are part of the ouput when an MPIR DLL is built using the native
Microsoft and Intel compilers.

best regards, Brian

[sisy...@optusnet.com.au]

From: highcal...@gmail.com
Sent: Friday, June 19, 2015 8:06 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR MinGW installation - "undefined reference
to '_imp____gmpz_init'

> I would like to call it from Matlab using mex files, and there, the
> compiler complains that it does not see any ".lib" files (when compiling
> with "mex ... -lmpir" it looks for a file "libmpir.lib") .

[snip]

> Compiler answer:
> "myfile.obj : error LNK2019: unresolved external symbol __imp___gmpf_init
> referenced in function "void __cdecl myfile(double)" "

That's interesting ... you've given the directive to link to "-lmpir", no
such library is found, but instead of croaking then and there the process
continues anyway ? (I don't know Matlab at all.)

Does it work if you rename libmpir.a (or whatever your existing mingw import
library is called) to libmpir.lib ?
It's a while since I've tried to use mingw-built libraries with a Microsoft
compiler and I'm not sure whether that simplistic approach works.

The fact that your object file is ".obj" instead of ".o" would indicate that
it's built with a Microsoft Compiler - so, if need be, you should be able to
build the requisite ".lib" file from the dll using your Microsoft Compiler
installation's lib tool (as Bill has hinted).

Cheers,
Rob

[Bill Hart]

On 19 June 2015 at 14:51, <sisy...@optusnet.com.au> wrote:

From: highcal...@gmail.com
Sent: Friday, June 19, 2015 8:06 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] Re: MPIR MinGW installation - "undefined reference to '_imp____gmpz_init'

I would like to call it from Matlab using mex files, and there, the compiler complains that it does not see any ".lib" files (when compiling with "mex ... -lmpir" it looks for a file "libmpir.lib") .

[snip]

Compiler answer:
"myfile.obj : error LNK2019: unresolved external symbol __imp___gmpf_init referenced in function "void __cdecl myfile(double)" "

That's interesting ... you've given the directive to link to  "-lmpir",  no such library is found, but instead of croaking then and there the process continues anyway ? (I don't know Matlab at all.)

Does it work if you rename libmpir.a (or whatever your existing mingw import library is called) to libmpir.lib ?

I don't think this will work. The .lib format is a Microsoft format, the .a format is a *nix format.

 

It's a while since I've tried to use mingw-built libraries with a Microsoft compiler and I'm not sure whether that simplistic approach works.

The fact that your object file is ".obj" instead of ".o" would indicate that it's built with a Microsoft Compiler - so, if need be, you should be able to build the requisite ".lib" file from the dll using your Microsoft Compiler installation's lib tool (as Bill has hinted).

Cheers,
Rob

[leif]

sisy...@optusnet.com.au wrote:
> From: highcal...@gmail.com
> Sent: Friday, June 19, 2015 8:06 PM
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] Re: MPIR MinGW installation - "undefined
> reference to '_imp____gmpz_init'
>
>> I would like to call it from Matlab using mex files, and there, the
>> compiler complains that it does not see any ".lib" files (when
>> compiling with "mex ... -lmpir" it looks for a file "libmpir.lib") .
> [snip]
>> Compiler answer:
>> "myfile.obj : error LNK2019: unresolved external symbol
>> __imp___gmpf_init referenced in function "void __cdecl myfile(double)" "
>
> That's interesting ... you've given the directive to link to "-lmpir",
> no such library is found, but instead of croaking then and there the
> process continues anyway ? (I don't know Matlab at all.)

Well, the non-presence of a library isn't necessarily a fatal error.
Anyway, it's of course better to first keep going to potentially emit
further error messages, in this case the unresolved symbols.

> [...]

> The fact that your object file is ".obj" instead of ".o" would indicate
> that it's built with a Microsoft Compiler - so, if need be, you should
> be able to build the requisite ".lib" file from the dll using your
> Microsoft Compiler installation's lib tool (as Bill has hinted).

The 'error LNK2019' certainly comes from a M$ compiler (more precisely,
its linker).

You can also use GNU Binutils' 'dlltool' to create M$-compatible import
libraries (*.LIB).


-leif

[highcal...@gmail.com]

Dear All,

Thanks for your help. I do not see a file exactly called "libmpir.dll", so if I really need to have "libmpir.lib" sitting in the .libs folder, how would I get the former to convert it via the MS lib tool to the latter?
I tried to convert the two existing ".dll" files in the .libs folder, namely "libmpir-3.dll" and "libmpir-16.dll" via the MS lib tool (accessed via cmd) to their respective ".lib" counterparts (eg. using this description). Then I used "-lmpir-3" resp. "-lmpir-16" in the mex command, which again returned the
"...unresolved external symbol __imp___gmpf_init ..." message. Specifically, I used the command

mex -IC:/MPIR/mpir-2.7.0/ -LC:/MPIR/mpir-2.7.0/.libs/ -LC:/MPIR/mpir-2.7.0/mpf/.libs -LC:/MPIR/mpir-2.7.0/printf/.libs mexlib.c

I also tried to add the MPIR root and .libs directories to the LIB and INCLUDE variables in the mexopts.bat settings file, which did not help anything.

Rob: The above message, for each mpf_... function, appear if I set the -lmpir or -lmpir-16 flag, but also if I don't.
Just changing the extension of "libmpir.la" to "libmpir.lib" did result in a "file corrupt" message after mex, as Bill conjectured.

Brian: How would I build an MPIR DLL using the native Microsoft and Intel compilers? Is this here a necessary extra step?

So, is the file "libmpir.lib" (or "libmpir.lib") needed and missing? Since the doc states that "-lmpir" needs to be set as a flag in the compile command.
Or - I think I ran ./configure with --disable-static --enable-shared; if so, was that wrong?
Thanks,
Pat

[Brian Gladman]

On 19/06/2015 15:10, highcal...@gmail.com wrote:
> Dear All,
>
> Thanks for your help. I do not see a file exactly called "libmpir.dll",
> so if I really need to have "libmpir.lib" sitting in the .libs folder,
> how would I get the former to convert it via the MS lib tool to the latter?
> I tried to convert the two existing ".dll" files in the .libs folder,
> namely "libmpir-3.dll" and "libmpir-16.dll" via the MS lib tool
> (accessed via cmd) to their respective ".lib" counterparts (eg. using
> this description

> <http://asawicki.info/news_1420_generating_lib_file_for_dll_library.html>).

> Then I used "-lmpir-3" resp. "-lmpir-16" in the mex command, which again
> returned the
> "...unresolved external symbol __imp___gmpf_init ..." message.
> Specifically, I used the command
>
> mex -IC:/MPIR/mpir-2.7.0/ -LC:/MPIR/mpir-2.7.0/.libs/
> -LC:/MPIR/mpir-2.7.0/mpf/.libs -LC:/MPIR/mpir-2.7.0/printf/.libs mexlib.c
>
> I also tried to add the MPIR root and .libs directories to the LIB and
> INCLUDE variables in the mexopts.bat settings file, which did not help
> anything.
>
> Rob: The above message, for each mpf_... function, appear if I set the
> -lmpir or -lmpir-16 flag, but also if I don't.
> Just changing the extension of "libmpir.la" to "libmpir.lib" did result
> in a "file corrupt" message after mex, as Bill conjectured.
>
> Brian: How would I build an MPIR DLL using the native Microsoft and
> Intel compilers? Is this here a necessary extra step?

First you need to install a version of Visual Stduio. This takes some
time but only has to be done infrewquently. Visual Studio 2013
Community and Visual Studio 2015 Community RC are both free and MPIR has
build files for both of these 'out of the box'.

You open Visual Studio and load the mpir.sln file, select the version
you want to build (e.g. DLL or Static Library), the architecture (e.g.
Nehalem), the configuration (e.g. x64 and Release) and then select
Build. After this you can load the mpir-tests.sln file to build and run
the tests.

Brian

[Bill Hart]

On 19 June 2015 at 16:10, <highcal...@gmail.com> wrote:

Dear All,

Thanks for your help. I do not see a file exactly called "libmpir.dll", so if I really need to have "libmpir.lib" sitting in the .libs folder, how would I get the former to convert it via the MS lib tool to the latter? 

I tried to convert the two existing ".dll" files in the .libs folder, namely "libmpir-3.dll" and "libmpir-16.dll" via the MS lib tool (accessed via cmd) to their respective ".lib" counterparts (eg. using this description).

I think libmpir-3.dll sounds old. The one you want to convert is the libmpir-16.dll, in my opinion.

 

Then I used "-lmpir-3" resp. "-lmpir-16" in the mex command, which again returned the  

"...unresolved external symbol __imp___gmpf_init ..." message. Specifically, I used the command

mex -IC:/MPIR/mpir-2.7.0/ -LC:/MPIR/mpir-2.7.0/.libs/ -LC:/MPIR/mpir-2.7.0/mpf/.libs -LC:/MPIR/mpir-2.7.0/printf/.libs mexlib.c

You shouldn't need the mpf directory in this command, nor the printf directory.

But as I don't know anything about mex, I can't really help with figuring out how to use it.

But as a general observation, I don't see where you are telling it what library to use. There could be 100 libraries in that .libs directory. Somehow I would guess it needs to know which one to use.

 

I also tried to add the MPIR root and .libs directories to the LIB and INCLUDE variables in the mexopts.bat settings file, which did not help anything.

Rob: The above message, for each mpf_... function, appear if I set the -lmpir or -lmpir-16 flag, but also if I don't.
Just changing the extension of "libmpir.la" to "libmpir.lib" did result in a "file corrupt" message after mex, as Bill conjectured.

Brian: How would I build an MPIR DLL using the native Microsoft and Intel compilers? Is this here a necessary extra step?

You already have an mpir dll, namely libmpir-16.dll.

 

So, is the file "libmpir.lib" (or "libmpir.lib") needed and missing?

As explained, it's needed, but not missing. You have to create it yourself with the lib tool or the gnu tool mentioned.

 

Since the doc states that "-lmpir" needs to be set as a flag in the compile command. 

Or - I think I ran ./configure with --disable-static --enable-shared; if so, was that wrong?

That looks right for creating a dll. Since you have one, I guess you did that correctly.

Anyhow the error message above suggests something is linking against MPIR but the linker is somehow looking for an internal symbol (it's something to do with the complicated way symbols are handled in MinGW). This could be because your system PATH is not set to include the directory where the dll file is. Thus the Windows linker cannot find the internal symbols.

Unfortunately, this sort of problem is hard to resolve. I've seen it happen on Windows when a program links against a library which has additional dependencies. I don't know if that could be happening here.

There are various tools you can use on Windows to see what is missing, e.g. in the past I got some clues using Dependency Walker and reading lots of forum posts and documentation of the MinGW linker and the Microsoft linker.

Bill.

[Bill Hart]

You might have more luck building MPIR using Brian's MSVC build scripts instead of using the MinGW configure/make/make install, etc.

I guess you still need to know how to use mex, e.g. what PATH variables need to be set, what the files need to be called, and where they have to be place, what commands to use to operate it, etc.

Anyway, these sorts of problems are the main reason we offer the MSVC scripts. The MinGW build works fine (I use the dll's directly in another project I work on), but for work with native Windows programs, it is often just easier to use the native Windows tools (such as MSVC).

In theory it should be less uphill for Windows developers.

Bill. 

[sisy...@optusnet.com.au]

Interesting .... I didn't know that.
I've built mingw-compatible import libs from dynamic libs in the past with:

gendef xxxx.dll (creates xxxx.def)
dlltool --kill-at --input-def xxxx.def--output-lib libxxxx.a

Is that output libxxxx.a also M$-compatible ? .... even though the
libxxxx.a that gets built as part of the routine mingw build is (I gather)
not.
Or does it require different flags to achieve the M$-compatibility ?

Cheers,
Rob

[Brian Gladman]

On 19/06/2015 15:28, 'Bill Hart' via mpir-devel wrote:

> Anyhow the error message above suggests something is linking against
> MPIR but the linker is somehow looking for an internal symbol (it's
> something to do with the complicated way symbols are handled in MinGW).
> This could be because your system PATH is not set to include the
> directory where the dll file is.

On Windows it is possible to link directly to a DLL but this is more
normally done through a stub-library.

So on a native build on Windows the mpir.dll is accompanied by the stub
library mpir.lib. So an app links to the stub library which then links
to the DLL itself. IIRC a symbol 'sym' in the DLL becomes '__imp__sym'
in the stub library so it seems to me that the mingw/GCC build system is
not producing a stub library.

Brian

[Bill Hart]

So that second line creates a .a file?

According to this page:

https://en.wikipedia.org/wiki/List_of_archive_formats

.a is almost exclusively used for unix style static libraries. I can't see that as a necessary step in the creating of a dynamic library for use on Windows. Are you sure this step is required/correct? 

Bill.

Cheers,
Rob

[Bill Hart]

That sounds right to me. The mingw build doesn't produce a .lib file (stub library). You have to create one if you want to use the dll produced by mingw.

In fact, the stub library is apparently not required to use the dll with mingw, which I guess is why it doesn't create one. Internally, it uses the Microsoft linker, but I don't completely understand the precise mechanism.

 

Bill.

   Brian

[Bill Hart]

I just read that the naming convention is different on Windows than Linux. So we have:

libmpir.a    (Unix convention)

mpir.dll      (Windows convention)

mpir.lib      (Windows convention)

I do not know what needs to be passed to the mex command. However, on MinGW

-lmpir should find any of the above, but it won't find a file named libmpir.lib. Perhaps this is also important on Windows.

Bill.

[highcal...@gmail.com]

> This could be because your system PATH is not set to include the

> directory where the dll file is.

On Windows it is possible to link directly to a DLL but this is more
normally done through a stub-library.

So on a native build on Windows the mpir.dll is accompanied by the stub
library mpir.lib.  So an app links to the stub library which then links
to the DLL itself.  IIRC a symbol 'sym' in the DLL becomes '__imp__sym'
in the stub library so it seems to me that the mingw/GCC build system is
not producing a stub library.

That sounds right to me. The mingw build doesn't produce a .lib file (stub library). You have to create one if you want to use the dll produced by mingw.

In fact, the stub library is apparently not required to use the dll with mingw, which I guess is why it doesn't create one. Internally, it uses the Microsoft linker, but I don't completely understand the precise mechanism.

Bill.

   Brian

Ok I have tried building stub libraries (containing only one column with the names "__gmp_init" etc. of the functions used in the code, using the MS lib tool. Now using "-lmpir" or "-lmpir-16" in the mex command should find the libmpir-16.dll, which, I suppose, contains the addresses (locations) of the various function definitions, via the stub library?
It does not yet the job. I will try to read more mex documentation.
Is there anything like a MinGW path variable I would be able to set? I am trying currently also to edit the mexopt.bat file which is called at the beginning of mex execution.
Thanks.

[Bill Hart]

On 19 June 2015 at 23:15, <highcal...@gmail.com> wrote:

> This could be because your system PATH is not set to include the

> directory where the dll file is.

On Windows it is possible to link directly to a DLL but this is more
normally done through a stub-library.

So on a native build on Windows the mpir.dll is accompanied by the stub
library mpir.lib.  So an app links to the stub library which then links
to the DLL itself.  IIRC a symbol 'sym' in the DLL becomes '__imp__sym'
in the stub library so it seems to me that the mingw/GCC build system is
not producing a stub library.

That sounds right to me. The mingw build doesn't produce a .lib file (stub library). You have to create one if you want to use the dll produced by mingw.

In fact, the stub library is apparently not required to use the dll with mingw, which I guess is why it doesn't create one. Internally, it uses the Microsoft linker, but I don't completely understand the precise mechanism.

Bill.

   Brian

Ok I have tried building stub libraries (containing only one column with the names "__gmp_init" etc. of the functions used in the code, using the MS lib tool. Now using "-lmpir" or "-lmpir-16" in the mex command should find the libmpir-16.dll, which, I suppose, contains the addresses (locations) of the various function definitions, via the stub library?

I guess that is the idea. Is your stub library named correctly now?

 

It does not yet the job. I will try to read more mex documentation.
Is there anything like a MinGW path variable I would be able to set?

Is mex a MinGW application? If not then setting a path variable in MinGW won't do anything.

You need to set your Windows PATH enviroment variable (I think that is where Windows looks for dll's). This has nothing to do with MinGW. Remember to use a full Windows path, not a unix one.

 

If mex is a MinGW application, set PATH in MinGW. Remember to use a unix path, not a Windows one.

> I am trying currently also to edit the mexopt.bat file which is called at the beginning of mex execution.

Thanks.

--

[sisy...@optusnet.com.au]

From: 'Bill Hart' via mpir-devel
Sent: Saturday, June 20, 2015 12:46 AM
To: mpir-devel

Subject: Re: [mpir-devel] Re: MPIR MinGW installation - "undefined reference
to '_imp____gmpz_init'

> >I've built mingw-compatible import libs from dynamic libs in the past
> >with:
>>
>> gendef xxxx.dll (creates xxxx.def)
>> dlltool --kill-at --input-def xxxx.def--output-lib libxxxx.a

[snip]

> So that second line creates a .a file?

Yes - it produces an import library (or "stub library", as Brian called it)
for the given dll.

> I can't see that as a necessary step in the creating of a dynamic library
> for use on Windows. Are you sure this step is required/correct?

Normally it's not needed, as the process that built the dll usually also
builds the import library.
But if you happen to have a dll without an accompanying import library, then
the above allows you to create the import library using only the dll. (I
think there are other convenient ways, in addition to gendef, of creating
the def file.)

As Brian said, it's possible to link directly to the dll, but most build
processes (eg configure scripts, cmake) will be looking for the import
library, rather than the dll itself. And it's generally far easier to create
the import library (if you don't already have it) than it is to modify that
build process such that the import library is not needed.
At runtime, of course, only the dll needs to be found.

With MinGW, both static and import libraries will have the ".a" extension.
Often, the import library is named ".dll.a" - ie "libxxxx.a" being a static
library, and "libxxxx.dll.a" being the import library for the dll.
And "-lxxxx" will enable linking to either the static or import library.
(Not sure which gets found first - I'm guessing it looks for the static
library before looking for the import library.)

IIRC, MinGW used to (and may still) look for ".lib" files. So "-lxxxx" would
seek out an appropriately named ".lib" file if no appropriately named ".a"
file could be found.

I've definitely mixed msvc-built libraries with mingw (and vice-versa, I
*think*) in the past, but that was before gcc-4.x.x, and before 64-bit mingw
compilers, and I can't remember whether it involved static libs, import
libs, or both.
(And it certainly didn't involve C++ libraries.)

Cheers,
Rob

[Bill Hart]

Ah, I see, you are talking about MinGW. I thought you were talking about MSVC.

In that case you may generate a .a file, yes.

Bill.

Cheers,
Rob

[highcal...@gmail.com]

On Windows it is possible to link directly to a DLL but this is more normally done through a stub-library.

So on a native build on Windows the mpir.dll is accompanied by the stub
library mpir.lib.  So an app links to the stub library which then links
to the DLL itself.  IIRC a symbol 'sym' in the DLL becomes '__imp__sym'
in the stub library so it seems to me that the mingw/GCC build system is
not producing a stub library.

That sounds right to me. The mingw build doesn't produce a .lib file (stub library). You have to create one if you want to use the dll produced by mingw.

In fact, the stub library is apparently not required to use the dll with mingw, which I guess is why it doesn't create one. Internally, it uses the Microsoft linker, but I don't completely understand the precise mechanism.

Bill.

   Brian

Ok I have tried building stub libraries (containing only one column with the names "__gmp_init" etc. of the functions used in the code, using the MS lib tool. Now using "-lmpir" or "-lmpir-16" in the mex command should find the libmpir-16.dll, which, I suppose, contains the addresses (locations) of the various function definitions, via the stub library?

I guess that is the idea. Is your stub library named correctly now?

The stub library is now named "libmpir-16.lib" and, as it looks like, found when adding "-lmpir" to the mex compilation command.
gcc works fine with "-lmpir" in MinGW and apparently uses "libmpir-16.dll" in .libs (because it fails if remove the latter). [So I understand gcc (and probably mex also) also look for "libmpir-xyz.lib", where xyz is an integer, when being passed "-lmpir"?]

But is the stub library (and/or the .lib file) correct? Along Brian's post, for eg. the required function "mpf_init" should have a '__imp__mpf_init" entry in the stub library "libmpir-16.def" output dump. However, these exact entries are not there; what I can find is eg. "__gmpf_clear" and "__gmpf_init = ___gmpf_set_prec_raw". Is that the same as  "__mpf_clear" and "__mpf_init"?  Should the "= ___gmpf_set_prec_raw" part also be removed when editing the ".def" file to create a .lib file?
What about three underscores versus two? The mex error also states with three underscores: "...unresolved external symbol __imp___gmpf_init in ...".

It looks like the libmpir.dll does not contain the required format for the exported functions when I want to create a .lib file (via the MS lib tool) from it. Here is what "libmpir-16.def" contains after the dumpbin command "dumpbin /exports libmpir-16.dll > libmpir-16.def" in the DOS cmd (before removing the first columns containing addresses from it as described eg. here):

-------- Selected contents of libmpir-16.def -------------------------------
Microsoft (R) COFF/PE Dumper Version 12.00.31101.0

Dump of file libmpir-16.dll
File Type: DLL
  Section contains the following exports for libmpir-16.dll
[...]
           1 ordinal base
         627 number of functions
         627 number of names

    ordinal hint RVA      name
          1    0 00009430 __combine_limbs
[...]
         47   2E 00049050 __gmp_printf
[...]
         89   58 00003100 __gmpf_clear
[...]
        116   73 00004710 __gmpf_init = ___gmpf_set_prec_raw
        117   74 00004750 __gmpf_init2
[...]
        135   86 00005560 __gmpf_set = ___gmpf_set_ui
[...]
        139   8A 00005710 __gmpf_set_prec_raw
[...]

  Summary
        1000 .CRT
        1000 .bss
        1000 .data
        5000 .edata
        D000 .eh_fram
        1000 .idata
        7000 .rdata
        1000 .reloc
       4F000 .text
        1000 .tls
-------------------------------- end selected content of "libmpir-16.def" --------------------------