Many users report using gfortran/gcc 4 on cygwin. How do you install these guys? Is it as simple as clicking experimental on cygwin installer, or what?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gcc4 is available for both cygwin-1.5 and cygwin1-7.
It is not experimental but just standard and it is the preferred
one on cygwin 1.7.
Just look for gcc4 packages.
Currently I am using just cygwin-1.7, that it is officially beta
but practically I judge a good release candidate.
Cygwin-1.5 will remain for Win9x and it will be unlikely
updated anymore.
I am the current cygwin package mantainer for lapack
and octave, and I would like to port atlas on cygwin.
I am not updating anymore the cygwin-1.5 packages,
and also other mantainers are starting to do so.
So for example, we have
on 1.5 lapack-3.0-8
on 1.7 lapack-3.1.1-2
I have not yet updated to lapack-3.2 as I was not sure
if atlas is compatible and I was unwilling to add further
complication on the work.
Regards
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I'll look at the compilers. Maybe I didn't get them because I did an update of existing packages as opposed to finding gcc4 in the package list . . .
gcc-4 do not accept anymore the "-mno-cygwin" flag.
A true cygwin-mingw cross compiler is planned to take over
that role.
To complete the build and pass all the test with
gcc-4.3.4 on cygwin-1.7.0-62 I was obliged to remove
-mpreferred-stack-boundary=2
from "probe_comp.c" otherwise the build is fine but the
check crash as already discussed on 3.9.9.
Could you make it as an option for configure ?
What about adding the cygwin on "probe_OS.c", I have not understood which system command are you using to
identify the system. I guess "uname -s" is used for the unix
and it can be used also for cygwin
on XP
$ uname -s
CYGWIN_NT-5.1
$ uname -a
CYGWIN_NT-5.1 xxxxxxx 1.7.0s(0.215/5/3) 20091012 10:21:06 i686 Cygwin
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think if you remove the -mpreferred-stack then you can't use Windows threads. Can you get gcc 4.4 on Windows yet? If you read the post by H.J. Lu at:
he claims that 4.4 has made this flag work more correctly.
As for detecting cygwin in configure, what do you want me to do that for?
As for the no-cygwin, what should I do there, if they have removed a feature in anticipation of solving it later? I cannot use a version of something that does not yet exist, so a flag that works on some versions is surely better than one that works on none?
Thanks,
Clint
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clint,
there is any specific test for the threads ?
"Make check" completed with no fails.
About no-cygwin it is only for your info, just in case you are surprised that it is not working on gcc-4 for cygwin.
The detection in configure is useful as the dll build procedure and dll name is different between cygwin and mingw.
Mingw use the windows standard name libatlas.dll while on cygwin it should be called cygatlas.dll.
Moreover on cygwin you are missing a "-lcygwin" for the dll build.
I need to check the compatibility of the dll's I succeded to build with the current blas/lapack packages.
Give me some days and eventually I will have a patch/source and a binary packages for testing in cygwin-1.7
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many users report using gfortran/gcc 4 on cygwin. How do you install these guys? Is it as simple as clicking experimental on cygwin installer, or what?
gcc4 is available for both cygwin-1.5 and cygwin1-7.
It is not experimental but just standard and it is the preferred
one on cygwin 1.7.
Just look for gcc4 packages.
Currently I am using just cygwin-1.7, that it is officially beta
but practically I judge a good release candidate.
Cygwin-1.5 will remain for Win9x and it will be unlikely
updated anymore.
I am the current cygwin package mantainer for lapack
and octave, and I would like to port atlas on cygwin.
I am not updating anymore the cygwin-1.5 packages,
and also other mantainers are starting to do so.
So for example, we have
on 1.5 lapack-3.0-8
on 1.7 lapack-3.1.1-2
I have not yet updated to lapack-3.2 as I was not sure
if atlas is compatible and I was unwilling to add further
complication on the work.
Regards
Marco
OK, I'll look at the compilers. Maybe I didn't get them because I did an update of existing packages as opposed to finding gcc4 in the package list . . .
As for lapack 3.2, I believe you can use it with ATLAS stable using the directions:
http://math-atlas.sourceforge.net/atlas_install/atlas_install.html#SECTION00041000000000000000
The later ATLAS developer releases can autobuild both lapack 3.1 and 3.2.
Thanks,
Clint
Clint,
please note:
gcc-4 do not accept anymore the "-mno-cygwin" flag.
A true cygwin-mingw cross compiler is planned to take over
that role.
To complete the build and pass all the test with
gcc-4.3.4 on cygwin-1.7.0-62 I was obliged to remove
-mpreferred-stack-boundary=2
from "probe_comp.c" otherwise the build is fine but the
check crash as already discussed on 3.9.9.
Could you make it as an option for configure ?
What about adding the cygwin on "probe_OS.c", I have not understood which system command are you using to
identify the system. I guess "uname -s" is used for the unix
and it can be used also for cygwin
on XP
$ uname -s
CYGWIN_NT-5.1
$ uname -a
CYGWIN_NT-5.1 xxxxxxx 1.7.0s(0.215/5/3) 20091012 10:21:06 i686 Cygwin
Marco
I think if you remove the -mpreferred-stack then you can't use Windows threads. Can you get gcc 4.4 on Windows yet? If you read the post by H.J. Lu at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
he claims that 4.4 has made this flag work more correctly.
As for detecting cygwin in configure, what do you want me to do that for?
As for the no-cygwin, what should I do there, if they have removed a feature in anticipation of solving it later? I cannot use a version of something that does not yet exist, so a flag that works on some versions is surely better than one that works on none?
Thanks,
Clint
Clint,
there is any specific test for the threads ?
"Make check" completed with no fails.
About no-cygwin it is only for your info, just in case you are surprised that it is not working on gcc-4 for cygwin.
The detection in configure is useful as the dll build procedure and dll name is different between cygwin and mingw.
Mingw use the windows standard name libatlas.dll while on cygwin it should be called cygatlas.dll.
Moreover on cygwin you are missing a "-lcygwin" for the dll build.
I need to check the compatibility of the dll's I succeded to build with the current blas/lapack packages.
Give me some days and eventually I will have a patch/source and a binary packages for testing in cygwin-1.7
Marco