Hi Arnaud,
Can't help you with your plea for NSIS help, sorry, but I'd like
to clarify...
> So, I have decided to download the GSL source files and recompile
> it with MYSYS ...
I presume you mean MSYS here; if not, what is MYSYS?
> / X86_64-mingw32.
Wouldn't that just produce 32-bit libraries anyway? If that tool
chain is properly named, it should be a cross-compiler creating object
code to run in the Win32 emulation layer, but optimised for the 64-bit
CPU instruction set, (which seems kind of anomalous anyway); expressed
in its full canonical host triplet form, the doublet "X86_64-mingw32"
expands to "X86_64-pc-mingw32" [1], and the "mingw32" component is
explicitly reserved to represent a Win32 host.
A true Win64 compiler *should* specify the host OS as "mingw64". [2]
[1] Should the CPU designator not be "x86_64"? These canonical
host triplets are intended to be parsed by platform agnostic tools;
upper vs. lower case distinctions are significant:
$ ./config.sub X86_64-mingw32
Invalid configuration `X86_64-mingw32': machine `X86_64' not
recognized
but:
$ ./config.sub x86_64-mingw32
x86_64-pc-mingw32
[2] Those responsible for the mingw-w64 project fork, (which is
*not* affiliated with the MinGW Project), need to get this properly
registered with the GNU `config' maintainer:
$ ./config.sub x86_64-mingw64
Invalid configuration `x86_64-mingw64': system `mingw64' not
recognized
Their continued use of "mingw32", which should unequivocally represent
the Win32 series of OSes, is an anomaly which needs to be resolved.
--
Regards,
Keith.
------------------------------------------------------------------------------
_______________________________________________
GnuWin32-Users mailing list
GnuWin32-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnuwin32-users