On Aug 28, 9:59 am, "jason" <[email protected]> wrote:
> Hi
>
> I think I know why the mingw64 dll builds fail , for multiple functions files
> ie aors_err2_n.asm , in the MSVC build yasm emits both functions in a single
> "unit" , whereas under mingw64 we create two links add and sub versions (like
> we do for unix) , and also yasm still emits both functions , so we end up
> with two copys. The same must happen in the static build , but it doesn't
> seem to matter?
> I was planning to get rid of such complications ( or rather move them to
> development machines only , much like autotools generates Makefile.in) , a
> small script should easily take of it.
>
> For the t-locale test , is there no way that MSVC will pass it ? , if so I'll
> ifdef it out , with ! _MSC_VER , because under mingw I think I can get it to
> pass , it looks like the redefinition of localenv just needs a DECLSPEC
The reason this test fails on Windows if the locale routine is defined
as a global is that the localconv symbol duplicates one in the MSVC
runtime library.
I have never worried about this test failure but it is trivial to get
it to pass since I can force the linker to build its output even if
there are multiple symbols and it will use the local symbol in
preference.
Brian
--
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.
