MPIR.2.5.1 shared library using mingw64

[Pavel Holoborodko]

Dear All,

This is my first mail to the group. I want to thank developers for creating this beautiful and very helpful library.

I've been using it for several years (relying on MSVC build - special thanks to Brian Gladman) in my projects. 

Now I'm transferring to mingw64 environment, and have encountered problem in building shared library of MPIR-2.5.1.  

 

I've tried to compile the latest stable version MPIR.2.5.1 using mingw64 with following configuration:

./configure --prefix=/mingw --host=x86_64-w64-mingw32 --enable-fat --disable-static --enable-shared --enable-gmpcompat

After that compilation went fine, but linker choked up with:

libtool: link: x86_64-w64-mingw32-gcc -std=gnu99 -shared .libs\\libmpir.la.lnkscript   -O2 -m64 -Wl,--export-all-symbols -Wl,--output-def -Wl,.libs/libmpir-3.dll.def   

-o .libs/libmpir-7.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libmpir.dll.a

Creating library file: .libs/libmpir.dll.a

mpn\\.libs\\addmul_2.o:addmul_2.as:(.text+0x0): multiple definition of `__gmpn_addmul_2'

mpn\\.libs\\redc_2.o:redc_2.c:(.text+0x0): first defined here

collect2: ld returned 1 exit status 

***

Interestingly, 2.5.0 compiles fine under the same settings.

I would appreciate any help in this regard.

Pavel Holoborodko.

--

Multiprecision Computing Toolbox for MATLAB

http://www.advanpix.com/

[Bill Hart]

This does look like a real live bug. Hopefully someone will fix it
soon. Thanks for the report, and sorry for the delay in replying.

Bill.

On May 14, 3:45 am, Pavel Holoborodko <pa...@holoborodko.com> wrote:
> Dear All,
>
> This is my first mail to the group. I want to thank developers for creating
> this beautiful and very helpful library.
> I've been using it for several years (relying on MSVC build - special
> thanks to Brian Gladman) in my projects.
>
> Now I'm transferring to mingw64 environment, and have encountered problem
> in building shared library of MPIR-2.5.1.
>
> I've tried to compile the latest stable version MPIR.2.5.1 using mingw64
> with following configuration:
>
> ./configure --prefix=/mingw --host=x86_64-w64-mingw32 --enable-fat
> --disable-static --enable-shared --enable-gmpcompat
>
> After that compilation went fine, but linker choked up with:
>
> libtool: link: x86_64-w64-mingw32-gcc -std=gnu99 -shared
> .libs\\libmpir.la.lnkscript   -O2 -m64 -Wl,--export-all-symbols
> -Wl,--output-def -Wl,.libs/libmpir-3.dll.def
> -o .libs/libmpir-7.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
> -Xlinker .libs/libmpir.dll.a
> Creating library file: .libs/libmpir.dll.a

> *mpn\\.libs\\addmul_2.o:addmul_2.as:(.text+0x0): multiple definition of
> `__gmpn_addmul_2'*
> *mpn\\.libs\\redc_2.o:redc_2.c:(.text+0x0): first defined here*

[Pavel Holoborodko]

Thank you for taking this problem under consideration. 

To see the full picture I've tried to compile MPIR from SVN\trunk. 

There are many errors coming from Assembler (as was anticipated by Brian). 

Cause seems to be simple enough to fix, but I have little experience with Assembler.

Hope this report will help somehow. Please see error messages at the end of the mail. 

***

On a very different topic. 

I've been using MPIR (through MPFR and MPC) to develop special plugin for MATLAB, which provides numerical methods in arbitrary precision for the system.

It covers basic math, linear algebra, optimization, ODE, integration, special functions, etc. 

Product is commercial, full name is Multiprecision Computing Toolbox for MATLAB, website: http://advanpix.com.

MPIR library is acknowledged on the main page of the project, as well as in "Info" section (shipped with plugin):

http://www.advanpix.com/documentation/mp-info/

I have no idea if this is appropriate, but can I ask you to reference my toolbox from MPIR page?

***

Errors coming from Assembler:

libtool: compile:  x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_fat_divrem_1 -O2 -m64 -c fat_divrem_1.c  -DDLL

_EXPORT -DPIC -o .libs/fat_divrem_1.o

C:\Users\Pavel\AppData\Local\Temp\ccHSijVV.s: Assembler messages:

C:\Users\Pavel\AppData\Local\Temp\ccHSijVV.s:25: Error: incorrect register `C%:e\sUis'e russ\ePda vweilt\hA p`pq' suDfaftiax\

ocal\Temp\ccpHqXIY.s: Assembler messages:

C:\Users\Pavel\AppData\Local\Temp\ccpHqXIY.s:23: Erromake[2]: r:*** [fat_divexact_byfobm1.lo] Error 1

ncorrect register `%ebx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccj23bx2.s: Assembler messages:

C:\Users\Pavel\AppData\Local\Temp\ccj23bx2.s:31: Error: register type mismatch for `bsf'

C:\Users\Pavel\AppData\Local\Temp\ccj23bx2.s:82: Error: incorrect register `%r9d' used with `q'C :s\uUfsfeirxs\P

vel\ACp:p\DUastae\rLso\cPaalv\eTle\mApp\pcDcaXt0aE\aLQo5c.asl:\ ATsesmepm\bclcejr2 3mbexs2s.asg:make[2]: e1s1*** [fat_divexact_by3c.lo] Error 1:0

:

CE:\Ursreorrs:\ Pavienlc\oArprpeDcatt ar\eLgoicsatle\rT e`m%pr\9cdc'X 0uEsaeQd5 .wsi:t5h3 :` q' Esurfrfoirx:

ncorrect register `%ecx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:67: Error: incorrect register `%r8d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:113: Error: incorrect register `%edx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:120: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:121: Error: operand type mismatch for `make[2]: ad*** [fat_divexact_1.lo] Error 1c'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:128: Error: incorrect register `%r9d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:131: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:132: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:161: Error: incorrect register `%edx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:168: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:169: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:176: Error: incorrect register `%r9d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:179: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:180: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:195: Error: incorrect register `%ecx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:209: Error: incorrect register `%r8d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:225: Error: incorrect register `%esi' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:232: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:239: Error: incorrect register `%r9d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:243: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:290: Error: incorrect register `%ebp' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:311: Error: incorrect register `%edx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:318: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:319: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:326: Error: incorrect register `%r10d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:329: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:330: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:355: Error: incorrect register `%esi' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:362: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:369: Error: incorrect register `%r10d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:373: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:394: Error: incorrect register `%ecx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:410: Error: incorrect register `%r8d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:432: Error: register type mismatch for `bsf'

C:\Users\Pavel\AppData\Local\Temp\ccX0EaQ5.s:451: Error: incorrect register `%ebp'libtool: compile:  x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..

-D__GMP_WITHIN_GMP -I.. -DOPERATION_fat_divrem_2 -O2 -m64 -c fat_divrem_2.c  -DDLL_EXPORT -DPIC -o .libs/fat_divrem_2.o u

d with `q' suffix

make[2]: *** [fat_divrem_1.lo] Error 1

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s: Assembler messages:

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:42: Error: operand type mismatch for `sub'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:43: Error: operand type mismatch for `sbb'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:88: Error: incorrect register `%edx' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:95: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:96: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:103: Error: incorrect register `%r14d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:109: Error: operand type mismatch for `add'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:110: Error: operand type mismatch for `adc'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:121: Error: incorrect register `%r9d' used with `q' suffix

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:137: Error: operand type mismatch for `sub'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:148: Error: operand type mismatch for `sub'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:149: Error: operand type mismatch for `sbb'

C:\Users\Pavel\AppData\Local\Temp\ccG16MSv.s:185: Error: operand type mismatch for `add'

make[2]: *** [fat_divrem_2.lo] Error 1

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To post to this group, send email to mpir-...@googlegroups.com.
To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

[Brian Gladman]

On Fri, 25 May 2012 12:03:11 +0900
Pavel Holoborodko <pa...@holoborodko.com> wrote:

> Thank you for taking this problem under consideration.
>
> To see the full picture I've tried to compile MPIR from SVN\trunk.
> There are many errors coming from Assembler (as was anticipated by
> Brian). Cause seems to be simple enough to fix, but I have little
> experience with Assembler.
>
> Hope this report will help somehow. Please see error messages at the
> end of the mail.

Hi Pavel,

Thank you for the further detail.

Interestingly the error reports contain AT&T register definitions,
which means that your build is not using the Windows assembler files
as we expected (all of which use Intel syntax). Maybe it is possible
to add stubs to the Unix/Linux x64 assembler to allow it to be used on
Windows x64 but I am rather doubtful about this.

Anyway, these errors are not the errors I anticipated!

If the mingw64 build is correctly using the Unix/Linux assembler (as
your reported errors suggest) then I have no idea what is happening.

All of which serves to confirm that we can't expect the mingw64 build
to work unless someone who needs, uses and understands how it wworks
volunteers to maintain it.

Brian

[Pavel Holoborodko]

All of which serves to confirm that we can't expect the mingw64 build

to work unless someone who needs, uses and understands how it wworks
volunteers to maintain it. 

I can try to help somehow with mingw64 support - but I have no idea about its architecture & GCC Assembler and other needed stuff. 

Maybe it is just simpler to roll back to mpir.dll built by MSVC.

 

Pavel.

[Bill Hart]

It looks like you supplied --enable-fat when configuring MPIR.

This is not supported under MinGW.

Bill.

[Pavel Holoborodko]

2.5.0 compiles fine with --enable-fat with all tests passing.

Then how I can compile mpir so that binaries will work on wide range
of CPUs? Generic C build, --march, else? Could you teach me?

Thanks in advance.
Pavel.

[Bill Hart]

I don't even know if building a fat binary with MinGW64 is even
possible, even in theory.

My guess is 2.5.0 was simply ignoring the --enable-fat flag.

As far as I know, building with the 32 bit version of MinGW supports
--enable-fat though. But that is no use to you as you want a 64 bit
binary.

To build a binary that runs on a wide range of processors, you could try

./configure --build=x86_64-w64-mingw32

This should run on all x86_64 processors. This won't be as fast as a
true fat binary though. It just selects lowest common denominator
assembly files.

Bill.

[Pavel Holoborodko]

I see, 

Bill, thank you for the clarification on mingw support specifics.

Brian, is there any equivalent of --enable-fat in Visual Studio build of MPIR?

Thank you.

Pavel Holoborodko

--

Multiprecision Computing Toolbox for MATLAB.

http://www.advanpix.com/ 

[Brian Gladman]

On Mon, 28 May 2012 13:51:21 +0900
Pavel Holoborodko <pa...@holoborodko.com> wrote:

> I see,
>
> Bill, thank you for the clarification on mingw support specifics.
>
> Brian, is there any equivalent of --enable-fat in Visual Studio build
> of MPIR?

Hi Pavel,

I'm afraid not.

Brian

[Pavel Holoborodko]

Are there any technical difficulties for that? Maybe I can help with that if my skills are enough.

[Brian Gladman]

On Mon, 28 May 2012 16:05:28 +0900
Pavel Holoborodko <pa...@holoborodko.com> wrote:

> Are there any technical difficulties for that? Maybe I can help with
> that if my skills are enough.

The next version of MPIR has a Python based build generator that allows
any of the assembler options to be selected and built.

To build a FAT version would require a significant further development
of this build generator.

Here is an outline of what has to be done (this is probably wrong in
detail as I have not looked at this closely - Bill Hart has given a
better description).

In outline rather then picking up a single set of assembler code, a FAT
build has to pick up a number of sets, one set for each of the
architectures that the FAT build will contain.

Then for each such set, the assembler source code files are renamed and
copied to a FAT directory (for example, the file mpn_add.asm will
become amd_k8_mpn_add.asm, intel_i7_mpn_add.asm, ... one for each
architecture in the FAT build).

Then each of these files is scanned for external symbols and the
files are edited to change these symbols so that, for example, such
symbols in the assembler files for the amd k8 have a prefix such as
amd_k8_ added to them.

Then a C source code table has to be generated for each set of
assebler files, one such table being:

amd_k8_mpn_add
intel_i7_mpn_add
intel_core2_mpn_add
...

and these tables have to be added into the C file that initialises
the FAT build on forst use.

I have thought about doing this but it is quite a long way off at
the moment so if you want to have a go at it, please do. But it is a
very complex process and a pretty complex bit of Python code.

Brian

[jason]

Hi

I figured out what going on here , basically configure is failing to
populate config.h with the required
#define HAVE_NATIVE_mpn_addmul_2 1
and all the others , it has always done this on mingw64 but because of
the way the C file redc_2 uses addmul_2 it now causes a problem.A
quick fix is to delete the lines in the mpn/generic/redc_2.c file
where it trys to redefine addmul_2

I don't know why configure fails to populate config.h , it manages to
do the sym links

Jason

=================================================================

On May 14, 3:45 am, Pavel Holoborodko <pa...@holoborodko.com> wrote:

> Dear All,
>
> This is my first mail to the group. I want to thank developers for creating
> this beautiful and very helpful library.
> I've been using it for several years (relying on MSVC build - special
> thanks to Brian Gladman) in my projects.
>
> Now I'm transferring to mingw64 environment, and have encountered problem
> in building shared library of MPIR-2.5.1.
>
> I've tried to compile the latest stable version MPIR.2.5.1 using mingw64
> with following configuration:
>
> ./configure --prefix=/mingw --host=x86_64-w64-mingw32 --enable-fat
> --disable-static --enable-shared --enable-gmpcompat
>
> After that compilation went fine, but linker choked up with:
>
> libtool: link: x86_64-w64-mingw32-gcc -std=gnu99 -shared
> .libs\\libmpir.la.lnkscript   -O2 -m64 -Wl,--export-all-symbols
> -Wl,--output-def -Wl,.libs/libmpir-3.dll.def
> -o .libs/libmpir-7.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
> -Xlinker .libs/libmpir.dll.a
> Creating library file: .libs/libmpir.dll.a

> *mpn\\.libs\\addmul_2.o:addmul_2.as:(.text+0x0): multiple definition of
> `__gmpn_addmul_2'*
> *mpn\\.libs\\redc_2.o:redc_2.c:(.text+0x0): first defined here*

[Brian Gladman]

On Sun, 10 Jun 2012 08:07:39 -0700 (PDT)
jason <ja...@njkfrudils.plus.com> wrote:

> Hi
>
> I figured out what going on here , basically configure is failing to
> populate config.h with the required
> #define HAVE_NATIVE_mpn_addmul_2 1
> and all the others , it has always done this on mingw64 but because of
> the way the C file redc_2 uses addmul_2 it now causes a problem.A
> quick fix is to delete the lines in the mpn/generic/redc_2.c file
> where it trys to redefine addmul_2
>
> I don't know why configure fails to populate config.h , it manages to
> do the sym links

Doesn't configure scan the assembler files looking for PROLOGUE(symbol)
to determine whether to include HAVE_NATIVE_symbol in config.h?

If so, configure won't pick up the symbols because the Windows assembler
files don't have any PROLOGUE macros.

But this doesn't explain how it ever worked!

Brian

[Jason Moxham]

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To post to this group, send email to mpir-...@googlegroups.com.
To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

=============================================================================

yeah it scans them for PROLOGUE and GLOBAL_FUNC , but the sym links come from the file names , no idea why mingw64 should be different , i'm even using the same msys , and the compiler is not used here. I do some file name transformation but that is the last thing configure does , at the moment I'm stumped , have to let it stew for a while

Jason

[Cactus]

On Sunday, 10 June 2012 17:15:09 UTC+1, Jason Moxham wrote:

> Hi
>
> I figured out what going on here , basically configure is failing to
> populate config.h with the required
> #define HAVE_NATIVE_mpn_addmul_2 1
> and all the others , it has always done this on mingw64 but because of
> the way the C file redc_2 uses addmul_2 it now causes a problem.A
> quick fix is to delete the lines in the mpn/generic/redc_2.c file
> where it trys to redefine addmul_2
>
> I don't know why configure fails to populate config.h , it manages to
> do the sym links

Doesn't configure scan the assembler files looking for PROLOGUE(symbol)
to determine whether to include HAVE_NATIVE_symbol in config.h?

If so, configure won't pick up the symbols because the Windows assembler
files don't have any PROLOGUE macros.  

But this doesn't explain how it ever worked!

    Brian

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To post to this group, send email to mpir-...@googlegroups.com.

To unsubscribe from this group, send email to mpir-devel+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

=============================================================================

yeah it scans them for PROLOGUE and GLOBAL_FUNC , but the sym links come from the file names , no idea why mingw64 should be different , i'm even using the same msys , and the compiler is not used here. I do some file name transformation but that is the last thing configure does , at the moment I'm stumped , have to let it stew for a while 

 

================

But if the PROLOGUE and/or GLOBAL_FUNC macros are needed in assembler files in order to generate the HAVE_NATIVE_symbol defines in config.h, isn't their absence explained by the lack of these macros in my Windows assembler files?

       Brian

 

 

 

 

Jason

[Jason Moxham]

On Sunday, 10 June 2012 17:15:09 UTC+1, Jason Moxham wrote:
>
>
> > Hi
> >
> > I figured out what going on here , basically configure is failing to
> > populate config.h with the required
> > #define HAVE_NATIVE_mpn_addmul_2 1
> > and all the others , it has always done this on mingw64 but because of
> > the way the C file redc_2 uses addmul_2 it now causes a problem.A
> > quick fix is to delete the lines in the mpn/generic/redc_2.c file
> > where it trys to redefine addmul_2
> >
> > I don't know why configure fails to populate config.h , it manages to
> > do the sym links
>
> Doesn't configure scan the assembler files looking for PROLOGUE(symbol)
> to determine whether to include HAVE_NATIVE_symbol in config.h?
>
> If so, configure won't pick up the symbols because the Windows assembler
> files don't have any PROLOGUE macros.
>
> But this doesn't explain how it ever worked!
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to

> mpir-devel+...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.
>
> =============================================================================
>
>
> yeah it scans them for PROLOGUE and GLOBAL_FUNC , but the sym links come
> from the file names , no idea why mingw64 should be different , i'm even
> using the same msys , and the compiler is not used here. I do some file
> name transformation but that is the last thing configure does , at the
> moment I'm stumped , have to let it stew for a while


================

> But if the PROLOGUE and/or GLOBAL_FUNC macros are needed in assembler
> files in order to generate the HAVE_NATIVE_symbol defines in config.h,
> isn't their absence explained by the lack of these macros in my Windows
> assembler files?


Brian




>
>



> Jason
>

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

To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/nuUwEeDf2rkJ.

To post to this group, send email to mpir-...@googlegroups.com.

To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

============================================================================================

Yep :( , the assembler files are definitely compiled and not the C one's so they must be used and be correct , WHEW.....

I think for mpir-2.5.2 I'll just remove the redc_2 file for now , so at least mingw64 users can get on(as redc_2 is not used anywhere yet)

For MPIR-2.6 either we parse your windows entry points or perhaps lets make another directory for mingw64 only in AT&T format win abi.If we do this msvc can use masm and the rest can dump yasm and use gas. It not really that much more effort , as the mingw64 directory is like a halfway stage to our current x86_64w directory. I'm prepared to do the mingw64 bits as even if I'm really pressed for time there is a really quick way to do it even though it does waste a few cycles . The other issue it makes easier is that I want to totally rearrange the x86_64 directory structure basically to accommodate a lowest common denominator build and save space/speed in a fat build.

Jason

[Cactus]

On Sunday, 10 June 2012 19:49:37 UTC+1, Jason Moxham wrote:

On Sunday, 10 June 2012 17:15:09 UTC+1, Jason Moxham wrote:
>
>
> > Hi
> >
> > I figured out what going on here , basically configure is failing to
> > populate config.h with the required
> > #define HAVE_NATIVE_mpn_addmul_2 1
> > and all the others , it has always done this on mingw64 but because of
> > the way the C file redc_2 uses addmul_2 it now causes a problem.A
> > quick fix is to delete the lines in the mpn/generic/redc_2.c file
> > where it trys to redefine addmul_2
> >
> > I don't know why configure fails to populate config.h , it manages to
> > do the sym links
>
> Doesn't configure scan the assembler files looking for PROLOGUE(symbol)
> to determine whether to include HAVE_NATIVE_symbol in config.h?
>
> If so, configure won't pick up the symbols because the Windows assembler
> files don't have any PROLOGUE macros.  
>
> But this doesn't explain how it ever worked!
>
>     Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to

> mpir-devel+unsubscribe@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.
>
> =============================================================================
>
>
> yeah it scans them for PROLOGUE and GLOBAL_FUNC , but the sym links come
> from the file names , no idea why mingw64 should be different , i'm even
> using the same msys , and the compiler is not used here. I do some file
> name transformation but that is the last thing configure does , at the
> moment I'm stumped , have to let it stew for a while

 
================

> But if the PROLOGUE and/or GLOBAL_FUNC macros are needed in assembler
> files in order to generate the HAVE_NATIVE_symbol defines in config.h,
> isn't their absence explained by the lack of these macros in my Windows
> assembler files?


       Brian
 

 

>  
>

 

> Jason
>

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/nuUwEeDf2rkJ.
To post to this group, send email to mpir-...@googlegroups.com.

To unsubscribe from this group, send email to mpir-devel+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

============================================================================================

Yep :( , the assembler files are definitely compiled and not the C one's so they must be used and be correct , WHEW.....

I think for mpir-2.5.2 I'll just remove the redc_2 file for now , so at least mingw64 users can get on(as redc_2 is not used anywhere yet)

For MPIR-2.6 either we parse your windows entry points or perhaps lets make another directory for mingw64 only in AT&T format win abi.If we do this msvc can use masm and the rest can dump yasm and use gas. It not really that much more effort , as the mingw64 directory is like a halfway stage to our current x86_64w directory. I'm prepared to do the mingw64 bits as even if I'm really pressed for time there is a really quick way to do it even though it does waste a few cycles . The other issue it makes easier is  that I want to totally rearrange the x86_64 directory structure basically to accommodate a lowest common denominator build and save space/speed in a fat build.

============

The other way of doing this is to add 

; PROLOGUE(symbol) 

lines to my files - the semicolon means that YASM ignores these lines but I think that configure will see them.  

If this doesn't work, I can add macros for PROLOGUE(x) and GLOBAL_FUNC(x)  that evaluate to NUL in YASM but be seen by configure.

   Brian

  

Jason

[Jason Moxham]

============
The other way of doing this is to add

; PROLOGUE(symbol)

lines to my files - the semicolon means that YASM ignores these lines but I
think that configure will see them.

If this doesn't work, I can add macros for PROLOGUE(x) and GLOBAL_FUNC(x)
that evaluate to NUL in YASM but be seen by configure.

Brian

================================================

That what I thought the GLOBAL_FUNC was for :)

I can easily add this with a script

Jason

[Brian Gladman]

I only used PROLOGUE as an example - as you say it might need to
be:

; GLOBAL_FUNC(symbol)

Some of my symbols are generated by macros so the script would have to
be quite smart to pick up all of them. I pick these symbols up from
these files in my mpir_config.py to make cfg.h so it might make sense
to rationalise how this is done - defining with lines:

; GLOBAL_FUNC(symbol)

for all symbols defined in the file would probably make my Python code
easier.

Brian