On Jun 2, 11:51 pm, Francesco Biscani <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Michael,
Hi Francesco,
> mabshoff wrote:
>
> | For 32 bits we are fixing the Cygwin issues and one goal for Dev1
> | [starting in a little less than two weeks] is to get that port up and
> | working again. MinGW's support for Python is allegedly problematic, at
> | least during the 2.4 release of python. I have not tried Python
> | 2.5+MinGW. Right now Windows Python 2.5 is build per default with
> | MSVC 2005 in 32 as well as 64 bit mode. It works perfect with Cygwin
> | in 32 bit mode, but there are some problems related to DLL address
> | space which are solvable. Python 2.6 as well as 3.0 will switch to
> | MSVC 2008 as default compiler.
> |
> | For 64 bit Windows the compilers by Microsoft [C/C++] and Intel
> | [Fortran] are the only technical viable option today. On the 64 bit
> | MinGW front things are changing, but I don't expect that compiler to
> | work well this year and we want to be done with the port this year,
> | hopefully by the fall. Once MinGW catches up we are more than happy to
> | support that compiler assuming we don't run into any showstoppers that
> | we cannot fix.
> |
> | For the Intel compilers: I am planning to add support for at least
> | Linux/Itanium, so the Intel compiler on Linux ought to work at some
> | point. The Intel compiler on Windows behaves differently than the
> | Linux version since the Linux version is supposed to be gcc compatible
> | while the Windows version is supposed to be a drop in replacement for
> | MSVC. So once we have MSVC working I will surely see how far I get
> | with the Intel compiler on Windows, too.
> |
> | In the we are willing to support any reasonable compiler, i.e. I am
> | adding Sun Forte support on Solaris at the moment, and obviously
> | welcome fixes from other platforms assuming they don't break the
> | other builds.
>
> Thanks for the info. I had no idea about the status of 64-bit MinGW, so
> I understand better your desire to support MSVC.
Some people are currently building Firefox with that toolchain which
is based on gcc 4.4 IIRC [otherwise it is gcc 4.3], so there is
definitely progress being made. Unfortunately it is currently only two
people with one of them doing the vast majority of the work, so let's
hope it gets all merged back into the official MinGW project soon. I
am not 100% clear on why, but the 64 bit effort seems to be something
that did not happen within the MinGW project.
> A couple of technical questions:
>
> 1) how do you cope with mixed C/C++ - Fortran builds under Windows,
> given that, AFAIK, it is generally not possible to mix these languages
> using different compilers (and that Microsoft does not provide a Fortran
> compiler)?
Fortran code build with the Intel compiler works flawless when linked
against MSVC code. I consider it so ironic that on Windows linking C
code with Fortran libraries "just works" while on Linux it can be and
often is a nightmare, especially once you start mixing and matching.
> 2) more generally, I think that such an effort must undergo tight
> coordination with upstream.
Yep.
> Given that AFAICT most open-source
> mathematical software is developed on the GCC toolchain, how do you cope
> with upstream projects using compiler/standard library features present
> only in GCC? I'm thinking mainly about stuff like assembly support, but
> also modern C++ standard library features. What do you do if, let's say,
> Singular starts using TR1's features implemented in GCC but not in MSVC?
> (in such case the solution could be using Boost's TR1 wrapper, but this
> requires notable interaction and coordination with the Singular devs)
There are three big C++ projects that will be difficult:
* Singular: upstream is aware of the project and willing to
cooperate. Singular itself uses its own macro based template system
since it was written before templates became standard.
* LinBox: too many templates ;) - but all kidding aside the LinBox
team is very happy to help us out and also integrate the fixes
upstream
* PolyBoRi: I didn't look too closely at this code base yet, but they
use some boost bits, which already should compile with MSVC. But I am
not so sure it will be trivial, so it is in my "difficult pile" until
proven innocent. The PolyBoRi people are also not exactly saddened
that we will port their code to MSVC.
If any of the above code or something else not listed here does not
compile with MSVC I am willing to try it with the Intel C++ compiler,
too. The Windows build of Sage, specifically the 64 bit build will
require commercial compilers anyway until the MinGW 64 bit port
works. Should bits of the fixes of our fixes be too invasive for
upstream we just have to carry a couple of patches and hope that down
the road we do find a better solution. I did some analysis of the work
we would need to do, so check out
http://wiki.sagemath.org/windows/general-package-analysis
It is fairly up to date. The general status of the Windows effort can
be seen at
http://wiki.sagemath.org/windows
and there are plenty of pages linked from there.
> Thanks and best regards,
>
> ~ Francesco.
Cheers,
Michael
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhEa2AACgkQFCtI0YdDCEuPrACeNBqnPZS0a0KAw0xsRGSDbHxk
> P2sAn2yzALjWeMQjdHeTgNvXYPS/7Yza
> =rap4
> -----END PGP SIGNATURE-----
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
