I forgot some for porting C: * MSVC is a C++ compiler, so malloc must always be cast, e.g. ulong * a = (ulong *) malloc(32*sizeof(ulong)); instead of ulong * a = malloc(32*sizeof(ulong));
* Addition of C++ guards around headers * Adding declspec(__dllexport__) in front of all prototypes in .h files * Various additional linker options are needed to build a dll correctly on Windows * If the project will be linked from other projects, especially if you intend to distribute binaries, you have to move libgcc_s and libpthread inside the library, rather than allow it to use the system libraries for this. Similar things often apply to GMP/MPIR as MinGW especially distributes its own versions of these, which may not be compatible with your project * Windows is a case insensitive file system. This means that filenames must be distinguishable under the constraints this implies. This can be especially problematic during builds. * MinGW doesn't seem to work well with paths containing spaces. * Various header files are named differently on Windows. Bill. On Wednesday, 27 August 2014 02:13:25 UTC+2, Bill Hart wrote: > > I am again very interested in having Windows 64 ports of various packages. > > At the top of my list are: > > * GAP > * Singular > * Pari/GP > > Note that MinGW2 is a much better way to do this than has previously been > available. It builds packages in a tiny fraction of the time it takes to > build with MinGW. It also fixes the broken parallel make that was in MinGW. > It has a nice package manager. The compiler seems stable. It 1000% better > in every way. In my opinion, a more or less native port of various packages > to MinGW2 is quite feasible. > > Note that the flint library generated only two warnings with MSVC after we > got it building with MinGW2. > > The biggest problem by far is the upstream projects who do not accept > patches into their repositories to support Windows, and aren't willing to > make the changes to their codebase to support Windows 64. Nor do they > continue to maintain the ports once it is done. > > This attitude in the Open Source community to Windows 64 really bugs me. > It's a decade old technology, and not going anywhere. > > A port of Sage to Windows 64 is probably not a viable project. It would > take years of effort by numerous individuals to accomplish. And it would > bitrot before it was even completed. But the fact that it isn't viable > right now doesn't mean that upstream projects shouldn't support Windows 64 > so that if Sage ever wants to do such a port, it would be possible. > > Five projects Sage doesn't have to worry about are: > > * flint > * gmp/mpir > * mpfr > * gmp-ecm > * GNU Scientific library > > They support Windows fully. In fact, these projects even build on MSVC > thanks to years of effort by Brian Gladman. > > For those unfamiliar with what a port to native Windows means, here is a > description of the steps involved for an ANSI C project (it's slightly > easier to port C99 projects to MinGW2 than ANSI C, but the MSVC compiler > does not have full C99 support): > > * Replace all occurrences of long and unsigned long with alternative types > (e.g. slong, ulong in flint or mp_limb_signed_t, mp_limb_t in GMP) since a > long is only 32 bits on 64 bit Windows > > * Ensure memory allocations do not mix allocating pointers and > words/limbs, e.g. long * a =malloc(32*sizeof(long)); void ** b = (void **) > a + 16; > > * Replace all format specifiers for printf, scanf, fscanf, sscanf. This > usually implies creating a project_printf function, for example, which > accepts all the usual format specifiers, but provides new ones (e.g. %wd, > %wu) for printing e.g. slong and ulong on Windows. Then use the new > project_flintf/scanf, etc ubiquitously. > > * Replace all integer constant literals, e.g. 123L with a macro, e.g. > WORD(123) which expands to 123L or 123LL depending on the platform. Similar > macro UWORD(123) for 123UL. Use ubiquitously. > > * Place all code that requires posix functionality (pipes, etc) inside > guards so it is not built on Windows. If the functionality is important to > retain as part of the core functionality, Windows equivalents need to be > implemented. For mathematical software written in C, this is usually not > common. For other kinds of software, this can be a massive task. > > * If you wish to support MSVC, some code may need to be ported from C99 > back to ANSI C style. This is not as difficult nowadays as it used to be. > MSVC is about 90% of the way there now. They for example support mixing > declarations with other code, they have numerous C99 headers available and > so on. > > * Replace intrinsics with Windows equivalents. Most of them exist on > Windows too, just with different names. > > * Rewrite code which uses GNU C extensions. (This is not usually a big > project.) > > Porting an assembly language project is quite a lot of work. > > * There is no inline assembler in MSVC on 64 bit Windows. So there has to > be fallback C for this platform. > > * Windows uses a different ABI for assembly functions than Linux, say. One > way around this is to write macros (such as the ones in GMP) which change > the order of registers on the way into and out of an assembly function > (only the ones actually used in the function). This is usually acceptable > because it doesn't affect any loops, except for perhaps moving them to > different alignments in memory. You can expect about a 5-10% slowdown with > this method. Given the scale of effort that would be required to rewrite > all the x86_64 assembly code in a project specially for Windows, this is an > acceptable compromise. (We use a different solution in MPIR. We have a lot > of our assembly code written in Yasm, which works on Linux and Windows. We > have separate assembly versions for many functions.) > > * If you are porting to MSVC, you might like to support stack unwinding. > This is quite a bit of work, but Brian Gladman does it for example for > MPIR. It is my understanding that GMP doesn't do this, however I have not > checked recently to see if this is still the case. > > Of course quite a lot of build system work may be necessary, even if using > Autotools, for either C or assembly projects. Some versions of Autotools > break the build on Windows, so you have to find a version which works on > that platform. > > It's definitely much easier to port a project to Windows in four steps. > Linux -> Cygwin -> Cygwin 64 -> MinGW64 -> MSVC. The biggest step is from > Cygwin64 -> MinGW64. The last step is very easy nowadays. It can be done > for a medium sized project (150,000 lines of C code) in a couple of man > weeks, most of which is just fixing bugs that didn't show up on Linux/GCC. > > I understand that Sage uses things like Lisp, Java, Python, Cython, etc. > So the above doesn't help much with Sage overall. But perhaps it will help > raise awareness for projects that are using C and assembly only. > > Bill. > > On Monday, 25 August 2014 10:15:41 UTC+2, Dr. David Kirkby (Kirkby > Microwave Ltd) wrote: >> >> It seems Sage really could do with a native windows port. I am wondering >> how practical it would be to make a version which is a subset of Sage, with >> something like Qt which runs on Windows, Linux, OSX and Solaris and has >> the look and feel of those platforms. >> >> It could make a Google Summer of Code project. >> >> If a small subset could be implemented, the chances are reasonable that >> others might port more bits. If it could do more than a scientific >> calculator, that would probably be enough to get people using it. Call it >> "Mini Sage" or something similar to indicate it is not the full version. >> >> I believe that there are some are some bits of Sage that uses fork and >> has have no Windows equivalent, so those bits could be left out. Perhaps at >> a later date a complete rewrite of such bits could form other GSOC >> projects. >> >> The download size of such a subset would be smaller than the full version >> and MUCH smaller that a virtual machine image, as one doesn't need to >> include a complete operating system too. >> >> Wolfram Research did at one point offer a subset of Mathematica, which i >> think was called Calc Centre, but I think it was a bit of a flop, so I >> don't think that they sell it any more. That might be an argument for not >> doing a partial native port. >> >> If a partial port was done, avoiding the need for a browser, one could >> use its own parser and provide a more confident interface. Although many >> are critical of Mathematica's interface, it is more consistent than that >> of Sage. >> >> Dave >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
