All the C tests pass now. Just checking the C++ ones.

On 2 April 2014 00:49, Bill Hart <goodwillh...@googlemail.com> wrote:

> Got it!
>
> /* __GMP_DECLSPEC supports Windows DLL versions of libmpir, and is empty in
>    all other circumstances.
>
>    When compiling objects for libmpir, __GMP_DECLSPEC is an export
> directive,
>    or when compiling for an application it's an import directive.  The two
>    cases are differentiated by __GMP_WITHIN_GMP defined by the GMP
> Makefiles
>    (and not defined from an application).
>
>    __GMP_DECLSPEC_XX is similarly used for libmpirxx.  __GMP_WITHIN_GMPXX
>    indicates when building libmpirxx, and in that case libmpirxx functions
> are
>    exports, but libmpir functions which might get called are imports.
>
>    libmp.la uses __GMP_DECLSPEC, just as if it were libmpir.la.  libmpir
> and
>    libmp don't call each other, so there's no conflict or confusion.
>
>    Libtool DLL_EXPORT define is not used.
>
>    There's no attempt to support GMP built both static and DLL.  Doing so
>    would mean applications would have to tell us which of the two is going
>    to be used when linking, and that seems very tedious and error prone if
>    using GMP by hand, and equally tedious from a package since autoconf and
>    automake don't give much help.
>
>    __GMP_DECLSPEC is required on all documented global functions and
>    variables, the various internals in gmp-impl.h etc can be left
> unadorned.
>    But internals used by the test programs or speed measuring programs
>    should have __GMP_DECLSPEC, and certainly constants or variables must
>    have it or the wrong address will be resolved.
>
>    In gcc __declspec can go at either the start or end of a prototype.
>
>    In Microsoft C __declspec must go at the start, or after the type like
>    void __declspec(...) *foo()".  There's no __dllexport or anything to
>    guard against someone foolish #defining dllexport.  _export used to be
>    available, but no longer.
> */
>
>
>
> On 2 April 2014 00:45, Bill Hart <goodwillh...@googlemail.com> wrote:
>
>> What does definitely work is this:
>>
>> #define mpn_store __MPN(store)
>> __GMP_DECLSPEC mp_limb_t mpn_store __GMP_PROTO ((mp_ptr, mp_size_t,
>> mp_limb_t));
>>
>> Bill.
>>
>>
>> On 2 April 2014 00:38, Bill Hart <goodwillh...@googlemail.com> wrote:
>>
>>> Even if I extern __gmpn_store and don't include gmp-impl.h, it still
>>> segfaults.
>>>
>>> This is wild!
>>>
>>> Bill.
>>>
>>>
>>> On 2 April 2014 00:26, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>
>>>> Ah, no sorry, ignore that. It doesn't. Same problem.
>>>>
>>>>
>>>> On 2 April 2014 00:25, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>>
>>>>> It compiles correctly if it is declared with __GMP_PROTO instead of
>>>>> _PROTO.
>>>>>
>>>>> No idea why!!
>>>>>
>>>>> Bill.
>>>>>
>>>>>
>>>>> On 2 April 2014 00:21, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>>>
>>>>>> I think it is the compiler, not the linker. For a call to mpn_add_n
>>>>>> (also assembly) it emits:
>>>>>>
>>>>>>         call    *__imp___gmpn_add_n(%rip)
>>>>>>
>>>>>> For a call to mpn_store, it emits:
>>>>>>
>>>>>>         call    __gmpn_store
>>>>>>
>>>>>> The question is, why?
>>>>>>
>>>>>> Bill.
>>>>>>
>>>>>>
>>>>>> On 2 April 2014 00:10, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>>>>
>>>>>>> It's nothing to do with the MPN_ZERO macro. A straight call to
>>>>>>> mpn_store segfaults.
>>>>>>>
>>>>>>> Bill.
>>>>>>>
>>>>>>>
>>>>>>> On 1 April 2014 23:59, Bill Hart <goodwillh...@googlemail.com>wrote:
>>>>>>>
>>>>>>>> Yeah that seems more likely, doesn't it.
>>>>>>>>
>>>>>>>> Why on earth for just that one function though. It's totally
>>>>>>>> bizarre.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1 April 2014 23:57, Jean-Pierre Flori <jpfl...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Or maybe that's an binutils/ld bug as I guess ld is in charge of
>>>>>>>>> putting the right address in the call[q] arg.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to