GMP 4.1.4 on MinGW (Wintersteiger)

[Sisyphus]

----- Original Message ----- 
From: "Juro Bystricky" <jurobystricky at hotmail.com>
To: "Sisyphus" <sisyphus1 at optusnet.com.au>; <gmp-discuss at swox.com>;
"Christoph M. Wintersteiger" <christoph at winterstiger.at>
Sent: Monday, September 12, 2005 11:55 PM
Subject: Re: GMP 4.1.4 on MinGW (Wintersteiger)


> This is an old problem. See the filed bug report at
>
>
https://sourceforge.net/tracker/index.php?func=detail&aid=1176786&group_id=2435&atid=102435
>
>
> Basically, the  LD generates incorrect (or missing) relocation information
> in the DLL startup code.
> It is built with the default load address of 0x1000000. Loading the DLL at
> any other address will cause a
> GP fault. This will happen if any other DLL is loaded before GMP (.EXE use
> different load address).
>
> I successfully rebuilt GMP using the binutils-2-13-90-20021006-2.tar.gz.
> I installed the latest ("current" as of March 20/2005)
> Mingw/Msys/MingwRuntime but used the above mentioned binutils.
> All of the above should be available for download ot the official Mingw
> site.
>
> Alternatively,  make sure no other DLL uses the default start address of
> 0x1000000.
>

I found a different solution to the problem - one that's probably inferior
to Juro's solution. Ymmv, but it worked in my test situation, and it may be
of some interest so I'll mention it here.

Assuming we have a dynamic GMP lib (libgmp-3.dll), build the "other" lib as
a static library. Let's call that other lib 'libmydll.a'.

In my test, that involved running (in the cmd.exe shell):

gcc -c mydll.c
ar rc libmydll.a mydll.o

Then in the MSYS shell create 'mydll.dll' by running:

a2dll libmydll.a -o mydll.dll -L/path_to/gmp-4.1.4/.libs -lgmp.dll

(That is, I've linked to libgmp.dll.a - which is built in the .libs folder
when a "shared" build of GMP is done. I tried also to link directly to
libgmp-3.dll in the 'a2dll' command but, if it's possible to do that, then I
failed to find the right syntax - though I did manage to corrupt
libgmp-3.dll in the attempt :-)

Then (back in the cmd.exe shell) build the application by running:

gcc -o app.exe app.c \path_to\gmp_dll\libgmp-3.dll \path_to\my_dll\mydll.dll

'app.exe' then runs fine.

Presumably the commands that I ran in the cmd.exe shell could also have been
run in the msys shell. However, 'a2dll' will work only in the msys shell.

Just for the record, my earlier attempts to build mydll.dll and app.exe
involved running:

gcc -shared -o mydll.dll mydll.o mydll.def \path_to\GMP_dll\libgmp-3.dll
followed by:
gcc -o app.exe app.c \path_to\gmp_dll\libgmp-3.dll \path_to\my_dll\mydll.dll

That built everything successfully, but produced precisely the same runtime
error that Chris reported when running app.exe.

I also found what I initially thought to be a related error regarding the
building of the perl modules GMP (part of the GMP library source) and
Math::GMP (from cpan). Seems that it's no longer straightforward to build
those modules against a dynamic GMP library (libgmp-3.dll) on Win32 using
the MinGW (gcc) compiler. The GMP module source is currently set up to build
against a static library. To build against a dynamic gmp library requires
that the source code be modified to link either directly to libgmp-3.dll, or
to the import lib libgmp.dll.a. I used to have no trouble doing that.
There's still no problem building the GMP module against a static GMP
library - but with a dynamic GMP library, although the compilation of the
GMP perl module runs to completion without error or warning, a runtime error
occurs when running the test suite:

F:\GMP\gmp-4.1.4\demos\perl>dmake test
F:\Perl58_M\5.8.7\bin\perl.exe "-Iblib\lib" "-Iblib\arch" test.pl
1..123
# Running under perl version 5.008007 for MSWin32
# Current time local: Mon Sep 12 18:39:13 2005
# Current time GMT:   Mon Sep 12 08:39:13 2005
# Using Test.pm version 1.25
Can't load 'blib\arch/auto/GMP/GMP.dll' for module GMP: load_file:Invalid
access to memory location at F:/Perl58_M/5.8.7/lib/DynaLoader.pm line 230.
 at test.pl line 46
Compilation failed in require at test.pl line 46.
BEGIN failed--compilation aborted at test.pl line 46.
dmake:  Error code 130, while making 'test_dynamic'

The error can be generated by running a script that contains simply:

use GMP qw(:all);

The same problem occurs when trying to build the Math::GMP module from cpan
against a dynamic GMP. Again, the same error can be generated by running a
script that contains simply:

use Math::GMP;

In the building of both of those perl modules, a GMP.dll is built that in
turn needs libgmp-3.dll - which is what first made me think that there was a
connection between this problem and the problem that Chris has reported.
Like I said, I used to have no trouble building and using those modules
against libgmp-3.dll - but afaict I've never used a version of ld earlier
than 2.13.90 20030111. In view of what we read at the above link that Juro
provided we're forced to conclude that either this problem with the perl
modules is a different problem, or that I must have, in the past, been using
a pre-2.13.90 20030111 version of ld. At this stage I'm lacking the interest
to investigate further ...though I could probably be easily coerced into
looking a little deeper if anyone thinks it's worth doing.

Cheers,
Rob