On 18 April 2011 03:59, Sisyphus <[email protected]> wrote:
>
> ----- Original Message ----- From: "Jason"
>
>> you could also try
>> ./configure --build=none-w64-mingw32 for a pure C build , incase it's just
>> the
>> assembler that is having problems.
>
> (The above was from an off list exchange. Jason has also sent me his build
> of mpir-2.3.1 for reference - ie the entire build directory.
> Putting this discussion back on list.)
>
> Generic C build is pretty good. The only problem is that t-aors_1.exe won't
> build. All other tests build and pass.
> Here's the error:
>
> x86_64-w64-mingw32-gcc.exe -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../..
> -I../../tests -DNO_ASM -O3 -c t-aors_1.c
> t-aors_1.c:271:1: internal compiler error: in
> cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
> Please submit a full bug report,
> with preprocessed source if appropriate.
Looks like a compiler bug.
>
> Anyway - my ,main problem is looking more and more like a yasm issue, and
> that's *not* good news for me (as I don't code in assembler, and I've never
> used yasm).
>
> Jason, I keep seeing discrepancies (in our respective builds) in the number
> of underscores that precede the symbol name. In your config.log, I see:
>
> configure:26548: checking if globals are prefixed by underscore
> configure:26558: x86_64-w64-mingw32-gcc.exe -std=gnu99 -O2 -m64 -march=core2
> -mtune=core2 -c conftest.c >&5
> configure:26561: $? = 0
> configure:26579: result: no
>
> Whereas mine contains:
>
> configure:26540: checking if globals are prefixed by underscore
> configure:26550: x86_64-w64-mingw32-gcc.exe -std=gnu99 -O2 -m64 -march=k8
> -mtune=k8 -c conftest.c >&5
> configure:26553: $? = 0
> configure:26571: result: yes
>
> Is this something that's architecture dependent ? (If so, then I would think
> it possible that both configure scripts have got it right. If not, then one
> script has got it wrong .... and it's not difficult to guess which one that
> might be.)
>
The number of leading underscores is called the global symbol prefix,
and this is platform dependent.
> I have an AMD64 processor. Jason, what do you have ?
> I assume also it's a difference in our processors that accounts for the
> different -march and -mtune settings ? (For me, they're 'k8', whereas Jason
> has 'core2'.)
I would imagine.
>
> Is it known if *anyone* has successfully built a 64-bit mpir (with
> assembler) on an AMD64 box with the MinGW64 compiler ?
>
> Should the library that Jason built and sent over to me be usable on my
> machine ?
Probably not, due to the symbol prefix.
> It's not working for me :
>
> ######################################
> C:\_64\c>type mpir.c
> #include <stdio.h>
> #include <mpir.h>
>
> int main(void) {
> mpz_t y;
>
> mpz_init_set_str(y, "1101101101101", 2);
> mpz_out_str(0, 16, y);
>
> mpz_clear(y);
> return 0;
> }
>
>
> C:\_64\c>x86_64-w64-mingw32-gcc -o mpir.exe mpir.c -IC:/temp/temp
> -LC:/temp/temp/.libs -lmpir
> C:\Users\Rob\AppData\Local\Temp\ccguXd86.o:mpir.c:(.text+0x22): undefined
> reference to `__gmpz_init_set_str'
> C:\Users\Rob\AppData\Local\Temp\ccguXd86.o:mpir.c:(.text+0x38): undefined
> reference to `__gmpz_out_str'
> C:\Users\Rob\AppData\Local\Temp\ccguXd86.o:mpir.c:(.text+0x44): undefined
> reference to `__gmpz_clear'
> collect2: ld returned 1 exit status
>
> C:\_64\c>
> ######################################
>
> (That's probably enough questions for this post :-)
>
> Cheers,
> Rob
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
