Re: Failure in building GFortran on Cygwin
On Nov 30 16:36, Christopher Faylor wrote: On Fri, Nov 30, 2007 at 03:58:42PM +0100, Corinna Vinschen wrote: On Nov 30 07:26, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/30/2007 7:20 AM: However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. For 1.5.x, yes. But can we delete timezone() for 1.7.x, on the grounds that any binary that still uses the timezone function is old enough that it would benefit from re-porting to the latest cygwin sources anyway? I'm thinking along the same lines. While that breaks backward compatibility, I'm not overly concerned in case of applications which have never been ported to a newer Cygwin version the last 10 or so years. But we do have a fairly transparent way of dealing with this problem which will allow any ancient apps to continue to work. We used it for the transition from 32 - 64 bit file I/O. Unfortunately it doesn't work for variables. We can hide the timezone function, but how do we alias timezone to _timezone in libcygwin.a? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Corinna Vinschen wrote: Unfortunately it doesn't work for variables. We can hide the timezone function, but how do we alias timezone to _timezone in libcygwin.a? Why does the variable need to be renamed? Can't we continue to call it _timezone internally and then #define timezone _timezone in a public header? It looks like this is already what we get in cygwin/time.h if we simply stop defining __timezonefunc__. Or is pulluting the namespace with a macro called timezone too hideous? In that case we could try declaring it extern long timezone asm(_timezone); in the header. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Dec 1 03:14, Brian Dessent wrote:
Corinna Vinschen wrote:
Unfortunately it doesn't work for variables. We can hide the timezone
function, but how do we alias timezone to _timezone in libcygwin.a?
Why does the variable need to be renamed? Can't we continue to call it
_timezone internally and then #define timezone _timezone in a public
header? It looks like this is already what we get in cygwin/time.h if
we simply stop defining __timezonefunc__.
That's the default case starting with 1.5.25. You get timezone
by this #define in cygwin/time.h.
The problem right now is that this clashes with the previous definition
of `struct timezone'. What happens is this:
struct timezone { int foo; };// by including sys/time.h
[...]
#define timezone _timezone // sys/time.h includes cygwin/time.h
[...]
struct timezone tzp; // the application defines this tzp var
So `struct timezone tzp' becomes `struct _timezone tzp' which is
an unknown structure type.
I have a simple patch for this which just reorders sys/time.h slightly.
The effect is that the #define is pulled in front of the structure
definition so all timezone gets _timezone and that's it.
Or is pulluting the namespace with a macro called timezone too
hideous? In that case we could try declaring it extern long timezone
asm(_timezone); in the header.
Erm... sorry if my lack of assembler inlining shows, but that really
works? If so, it looks like a rather elegant solution to me. I'll give
it a try.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Corinna Vinschen wrote: [ snip sensible explanation that I had actually ran into in the past and then forgotten about ] Or is pulluting the namespace with a macro called timezone too hideous? In that case we could try declaring it extern long timezone asm(_timezone); in the header. Erm... sorry if my lack of assembler inlining shows, but that really works? If so, it looks like a rather elegant solution to me. I'll give it a try. Oops, I think it should be asm(__timezone) with two leading underscores, as specifying the assembler name like this bypasses the compiler automatically adding one. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Dec 1 04:13, Brian Dessent wrote: Corinna Vinschen wrote: [ snip sensible explanation that I had actually ran into in the past and then forgotten about ] Or is pulluting the namespace with a macro called timezone too hideous? In that case we could try declaring it extern long timezone asm(_timezone); in the header. Erm... sorry if my lack of assembler inlining shows, but that really works? If so, it looks like a rather elegant solution to me. I'll give it a try. Oops, I think it should be asm(__timezone) with two leading underscores, as specifying the assembler name like this bypasses the compiler automatically adding one. Works like a charm. I like this. I will apply a patch which removes timezone from the exported symbols in libcygwin.a and use the above expression in cygwin/time.h. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Corinna Vinschen wrote: Works like a charm. I like this. I will apply a patch which removes timezone from the exported symbols in libcygwin.a and use the above expression in cygwin/time.h. Should we handle _daylight the same way for consistency? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Dec 1 05:12, Brian Dessent wrote: Corinna Vinschen wrote: Works like a charm. I like this. I will apply a patch which removes timezone from the exported symbols in libcygwin.a and use the above expression in cygwin/time.h. Should we handle _daylight the same way for consistency? Hmm, yeah, why not? Given that I have to change cygwin/time.h anyway since I removed the __timezonefunc__ stuff erroneously... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Sat, Dec 01, 2007 at 11:31:55AM +0100, Corinna Vinschen wrote: On Nov 30 16:36, Christopher Faylor wrote: On Fri, Nov 30, 2007 at 03:58:42PM +0100, Corinna Vinschen wrote: On Nov 30 07:26, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/30/2007 7:20 AM: However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. For 1.5.x, yes. But can we delete timezone() for 1.7.x, on the grounds that any binary that still uses the timezone function is old enough that it would benefit from re-porting to the latest cygwin sources anyway? I'm thinking along the same lines. While that breaks backward compatibility, I'm not overly concerned in case of applications which have never been ported to a newer Cygwin version the last 10 or so years. But we do have a fairly transparent way of dealing with this problem which will allow any ancient apps to continue to work. We used it for the transition from 32 - 64 bit file I/O. Unfortunately it doesn't work for variables. We can hide the timezone function, but how do we alias timezone to _timezone in libcygwin.a? Why do you say that? It should just be a simple aliasing. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Dec 1 11:13, Christopher Faylor wrote:
On Sat, Dec 01, 2007 at 11:31:55AM +0100, Corinna Vinschen wrote:
On Nov 30 16:36, Christopher Faylor wrote:
But we do have a fairly transparent way of dealing with this problem which
will allow any ancient apps to continue to work. We used it for the
transition
from 32 - 64 bit file I/O.
Unfortunately it doesn't work for variables. We can hide the timezone
function, but how do we alias timezone to _timezone in libcygwin.a?
Why do you say that? It should just be a simple aliasing.
Because it doesn't work, AFAICS. Actual aliasing in localtime.cc as in
extern long timezone __attribute__ ((alias(_timezone)));
doesn't work because it breaks generating cygdll.a due to multiple
definitions of timezone, the function in times.cc, the variable in
localtime.cc.
Using the NEW_FUNCTIONS mechanism in Makefile.in doesn't work either.
Apply this patch:
Index: Makefile.in
===
RCS file: /cvs/src/src/winsup/cygwin/Makefile.in,v
retrieving revision 1.202
diff -u -p -r1.202 Makefile.in
--- Makefile.in 1 Dec 2007 13:04:43 - 1.202
+++ Makefile.in 1 Dec 2007 17:01:32 -
@@ -214,7 +214,8 @@ NEW_FUNCTIONS:=regcomp posix_regcomp \
stat _stat64 \
telldir _telldir64 \
tmpfile _tmpfile64 \
- truncate _truncate64
+ truncate _truncate64 \
+ timezone _timezone
API_VER:=$(srcdir)/include/cygwin/version.h
Index: include/cygwin/time.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/time.h,v
retrieving revision 1.7
diff -u -p -r1.7 time.h
--- include/cygwin/time.h 1 Dec 2007 13:49:45 - 1.7
+++ include/cygwin/time.h 1 Dec 2007 17:01:32 -
@@ -29,7 +29,7 @@ time_t __cdecl timegm (struct tm *);
extern int daylight __asm__ (__daylight);
#ifndef __timezonefunc__
-extern long timezone __asm__ (__timezone);
+extern long timezone;
#endif
#endif
When you build this application:
#include sys/time.h
int
main ()
{
printf (timezone = %p\n, timezone);
printf (_timezone = %p\n, _timezone);
return 0;
}
The result will be something like this:
$ ./test-timezone
timezone = 0x401170
_timezone = 0x611942c0
So timezone is not the same as _timezone in the application and
only _timezone will be handled inside of Cygwin.
Am I missing something?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Corinna Vinschen wrote: I've made another version of the Cygwin DLL, 1.5.25-3 With this new version of Cygwin, the problem, with which I started this thread, seems to be solved! Now the build of GFortran (20071201, trunk 130556) is completed without problems. Many thanks, Angelo. --- http://www.webalice.it/angelo.graziosi Facesti come quei che va di notte, che porta il lume dietro e se' non giova, ma dopo se' fa le persone dotte. DANTE, Purgatorio, XXII 67-69 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Angelo Graziosi wrote: Corinna Vinschen wrote: I've made another version of the Cygwin DLL, 1.5.25-3 With this new version of Cygwin, the problem, with which I started this thread, seems to be solved! Now the build of GFortran (20071201, trunk 130556) is completed without problems. Many thanks, Angelo. Yes, many thanks Corinna. Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Sat, Dec 01, 2007 at 06:11:56PM +0100, Corinna Vinschen wrote: On Dec 1 11:13, Christopher Faylor wrote: On Sat, Dec 01, 2007 at 11:31:55AM +0100, Corinna Vinschen wrote: On Nov 30 16:36, Christopher Faylor wrote: But we do have a fairly transparent way of dealing with this problem which will allow any ancient apps to continue to work. We used it for the transition from 32 - 64 bit file I/O. Unfortunately it doesn't work for variables. We can hide the timezone function, but how do we alias timezone to _timezone in libcygwin.a? Why do you say that? It should just be a simple aliasing. Because it doesn't work, AFAICS. Actual aliasing in localtime.cc as in extern long timezone __attribute__ ((alias(_timezone))); doesn't work because it breaks generating cygdll.a due to multiple definitions of timezone, the function in times.cc, the variable in localtime.cc. Using the NEW_FUNCTIONS mechanism in Makefile.in doesn't work either. Apply this patch: I'm investigating why this doesn't work now. Looks like more import magic is needed. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Nov 30 07:26, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/30/2007 7:20 AM: However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. For 1.5.x, yes. But can we delete timezone() for 1.7.x, on the grounds that any binary that still uses the timezone function is old enough that it would benefit from re-porting to the latest cygwin sources anyway? I'm thinking along the same lines. While that breaks backward compatibility, I'm not overly concerned in case of applications which have never been ported to a newer Cygwin version the last 10 or so years. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
[Forgot to CC the fortran list. Re-sending...] On Nov 29 17:05, Jerry DeLisle wrote: Angelo Graziosi wrote: /tmp/gcc/libgfortran/intrinsics/system_clock.c: In function 'system_clock_4': /tmp/gcc/libgfortran/intrinsics/system_clock.c:67: error: storage size of 'tzp' isn't known /tmp/gcc/libgfortran/intrinsics/system_clock.c:67: warning: unused variable 'tzp' /tmp/gcc/libgfortran/intrinsics/system_clock.c: In function 'system_clock_8': /tmp/gcc/libgfortran/intrinsics/system_clock.c:130: error: storage size of 'tzp' isn't known /tmp/gcc/libgfortran/intrinsics/system_clock.c:130: warning: unused variable 'tzp' [...] The Cygwin version is 1.5.25-2 (exp.). I can confirm this. I saw it last wekend trying to do my regular cygwin build of gfortran for the wiki. The build died and I assumed I did something wrong and was going to try back later. Well this is definitely a regression somewhere. Its not on the gfortran side which has not touched that file for several months. It could be something broke in the configure for cygwin. The error occurs in a conditional comapile: #if defined(HAVE_SYS_TIME_H) defined(HAVE_GETTIMEOFDAY) I will open a PR to track this. A simple testcase would have been much more helpful. From the name of the variable I assume that tzp is a `struct timezone' variable. Given that it's unused, and given that struct timezone is a BSDism which isn't present in the POSIX standard(*), it might be a good idea to just remove it entirely from the source or to keep it only when the build target is a BSD system. However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. Alas, we're stuck with the _timezone variable and we have to #define timezone _timezone at one point in the headers. The problem is that the above define happens in a Cygwin specific header after the definition of `struct timezone'. So the usage of `struct timezone' in application code results in a `struct _timezone', which is not defined and the above error occurs. AFAICS there are at least two ways to solve this problem, but I'm a bit unsure right now, which is the better one. Saty tuned. Corinna (*) gettimeofday's second parameter is void* in POSIX, see http://www.opengroup.org/onlinepubs/009695399/functions/gettimeofday.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Nov 29 17:05, Jerry DeLisle wrote: Angelo Graziosi wrote: /tmp/gcc/libgfortran/intrinsics/system_clock.c: In function 'system_clock_4': /tmp/gcc/libgfortran/intrinsics/system_clock.c:67: error: storage size of 'tzp' isn't known /tmp/gcc/libgfortran/intrinsics/system_clock.c:67: warning: unused variable 'tzp' /tmp/gcc/libgfortran/intrinsics/system_clock.c: In function 'system_clock_8': /tmp/gcc/libgfortran/intrinsics/system_clock.c:130: error: storage size of 'tzp' isn't known /tmp/gcc/libgfortran/intrinsics/system_clock.c:130: warning: unused variable 'tzp' [...] The Cygwin version is 1.5.25-2 (exp.). I can confirm this. I saw it last wekend trying to do my regular cygwin build of gfortran for the wiki. The build died and I assumed I did something wrong and was going to try back later. Well this is definitely a regression somewhere. Its not on the gfortran side which has not touched that file for several months. It could be something broke in the configure for cygwin. The error occurs in a conditional comapile: #if defined(HAVE_SYS_TIME_H) defined(HAVE_GETTIMEOFDAY) I will open a PR to track this. A simple testcase would have been much more helpful. From the name of the variable I assume that tzp is a `struct timezone' variable. Given that it's unused, and given that struct timezone is a BSDism which isn't present in the POSIX standard(*), it might be a good idea to just remove it entirely from the source or to keep it only when the build target is a BSD system. However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. Alas, we're stuck with the _timezone variable and we have to #define timezone _timezone at one point in the headers. The problem is that the above define happens in a Cygwin specific header after the definition of `struct timezone'. So the usage of `struct timezone' in application code results in a `struct _timezone', which is not defined and the above error occurs. AFAICS there are at least two ways to solve this problem, but I'm a bit unsure right now, which is the better one. Saty tuned. Corinna (*) gettimeofday's second parameter is void* in POSIX, see http://www.opengroup.org/onlinepubs/009695399/functions/gettimeofday.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Fri, 30 Nov 2007, Corinna Vinschen wrote: On Nov 30 07:26, Eric Blake wrote: According to Corinna Vinschen on 11/30/2007 7:20 AM: However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. For 1.5.x, yes. But can we delete timezone() for 1.7.x, on the grounds that any binary that still uses the timezone function is old enough that it would benefit from re-porting to the latest cygwin sources anyway? I'm thinking along the same lines. While that breaks backward compatibility, I'm not overly concerned in case of applications which have never been ported to a newer Cygwin version the last 10 or so years. And plus, renaming the function to, e.g., _cygwin_timezone will allow for a one-line fix for those applications... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Corinna Vinschen wrote:
[Forgot to CC the fortran list. Re-sending...]
On Nov 29 17:05, Jerry DeLisle wrote:
Angelo Graziosi wrote:
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_4':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: warning: unused
variable 'tzp'
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_8':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: warning: unused
variable 'tzp'
[...]
The Cygwin version is 1.5.25-2 (exp.).
I can confirm this. I saw it last wekend trying to do my regular cygwin
build of gfortran for the wiki. The build died and I assumed I did
something wrong and was going to try back later.
Well this is definitely a regression somewhere. Its not on the gfortran
side which has not touched that file for several months. It could be
something broke in the configure for cygwin. The error occurs in a
conditional comapile:
#if defined(HAVE_SYS_TIME_H) defined(HAVE_GETTIMEOFDAY)
I will open a PR to track this.
A simple testcase would have been much more helpful.
Here is code with the problem: Not super simple, but I think you can follow it.
Thanks for hellp
void
system_clock_4(GFC_INTEGER_4 *count, GFC_INTEGER_4 *count_rate,
GFC_INTEGER_4 *count_max)
{
GFC_INTEGER_4 cnt;
GFC_INTEGER_4 rate;
GFC_INTEGER_4 mx;
#if defined(HAVE_SYS_TIME_H) defined(HAVE_GETTIMEOFDAY)
struct timeval tp1;
struct timezone tzp;
if (sizeof (tp1.tv_sec) sizeof (GFC_INTEGER_4))
internal_error (NULL, tv_sec too small);
if (gettimeofday(tp1, tzp) == 0)
{
GFC_UINTEGER_4 ucnt = (GFC_UINTEGER_4) tp1.tv_sec * TCK;
ucnt += (tp1.tv_usec + 50 / TCK) / (100 / TCK);
if (ucnt GFC_INTEGER_4_HUGE)
cnt = ucnt - GFC_INTEGER_4_HUGE - 1;
else
cnt = ucnt;
rate = TCK;
mx = GFC_INTEGER_4_HUGE;
}
else
{
if (count != NULL)
*count = - GFC_INTEGER_4_HUGE;
if (count_rate != NULL)
*count_rate = 0;
if (count_max != NULL)
*count_max = 0;
return;
}
#elif defined(HAVE_TIME_H)
GFC_UINTEGER_4 ucnt;
if (sizeof (time_t) sizeof (GFC_INTEGER_4))
internal_error (NULL, time_t too small);
ucnt = time (NULL);
if (ucnt GFC_INTEGER_4_HUGE)
cnt = ucnt - GFC_INTEGER_4_HUGE - 1;
else
cnt = ucnt;
mx = GFC_INTEGER_4_HUGE;
#else
cnt = - GFC_INTEGER_4_HUGE;
mx = 0;
#endif
if (count != NULL)
*count = cnt;
if (count_rate != NULL)
*count_rate = TCK;
if (count_max != NULL)
*count_max = mx;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/30/2007 7:20 AM: However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. For 1.5.x, yes. But can we delete timezone() for 1.7.x, on the grounds that any binary that still uses the timezone function is old enough that it would benefit from re-porting to the latest cygwin sources anyway? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUB2U84KuGfSFAYARAgKkAKCy0XnLBoYOAGTgqDDn+gH4JbKUpACfWRzr HRu9Z0y0/Q1QIFs6isv8LhI= =+4Ey -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
On Fri, Nov 30, 2007 at 03:58:42PM +0100, Corinna Vinschen wrote: On Nov 30 07:26, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/30/2007 7:20 AM: However, this *is* a problem in the newlib/cygwin headers. Cygwin exports a timezone function and a _timezone variable. The timezone function was an ill-advised invention in Cygwin way back in the last century. Unfortunately it has to be kept for backward compatibility. For 1.5.x, yes. But can we delete timezone() for 1.7.x, on the grounds that any binary that still uses the timezone function is old enough that it would benefit from re-porting to the latest cygwin sources anyway? I'm thinking along the same lines. While that breaks backward compatibility, I'm not overly concerned in case of applications which have never been ported to a newer Cygwin version the last 10 or so years. But we do have a fairly transparent way of dealing with this problem which will allow any ancient apps to continue to work. We used it for the transition from 32 - 64 bit file I/O. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Failure in building GFortran on Cygwin
For the sake of completeness I want to flag the following.
Building GFortran CVS 20071129 trunk 130516 on Cygwin it fails in this
way:
...
libtool: compile: /tmp/gcc/build/./gcc/xgcc -B/tmp/gcc/build/./gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
/usr/local/gfortran/i686-pc-cygwin/include -isystem
/usr/local/gfortran/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I.
-I/tmp/gcc/libgfortran -I. -iquote/tmp/gcc/libgfortran/io
-I/tmp/gcc/libgfortran/../gcc -I/tmp/gcc/libgfortran/../gcc/config
-I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g
-O2 -MT system_clock.lo -MD -MP -MF .deps/system_clock.Tpo -c
/tmp/gcc/libgfortran/intrinsics/system_clock.c -o system_clock.o
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_4':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: warning: unused
variable 'tzp'
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_8':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: warning: unused
variable 'tzp'
make[3]: *** [system_clock.lo] Error 1
make[3]: Leaving directory `/tmp/gcc/build/i686-pc-cygwin/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/gcc/build/i686-pc-cygwin/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/tmp/gcc/build'
make: *** [all] Error 2
The build was configured (as always):
${gcc_dir}/configure --prefix=${prefix_dir} \
--exec-prefix=${prefix_dir} \
--sysconfdir=${prefix_dir}/etc \
--libdir=${prefix_dir}/lib \
--libexecdir=${prefix_dir}/lib \
--mandir=${prefix_dir}/share/man \
--infodir=${prefix_dir}/share/info \
--enable-languages=c,fortran \
--enable-bootstrap \
--enable-decimal-float=bid \
--enable-libgomp \
--enable-threads \
--enable-sjlj-exceptions \
--enable-version-specific-runtime-libs \
--enable-nls \
--enable-checking=release \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-win32-registry \
--with-system-zlib \
--without-included-gettext \
--without-x
The Cygwin version is 1.5.25-2 (exp.).
Cheers,
Angelo.
---
http://www.webalice.it/angelo.graziosi
Facesti come quei che va di notte,
che porta il lume dietro e se' non giova,
ma dopo se' fa le persone dotte.
DANTE, Purgatorio, XXII 67-69
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Failure in building GFortran on Cygwin
Angelo Graziosi wrote:
For the sake of completeness I want to flag the following.
Building GFortran CVS 20071129 trunk 130516 on Cygwin it fails in this
way:
...
libtool: compile: /tmp/gcc/build/./gcc/xgcc -B/tmp/gcc/build/./gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
/usr/local/gfortran/i686-pc-cygwin/include -isystem
/usr/local/gfortran/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I.
-I/tmp/gcc/libgfortran -I. -iquote/tmp/gcc/libgfortran/io
-I/tmp/gcc/libgfortran/../gcc -I/tmp/gcc/libgfortran/../gcc/config
-I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g
-O2 -MT system_clock.lo -MD -MP -MF .deps/system_clock.Tpo -c
/tmp/gcc/libgfortran/intrinsics/system_clock.c -o system_clock.o
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_4':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:67: warning: unused
variable 'tzp'
/tmp/gcc/libgfortran/intrinsics/system_clock.c: In function
'system_clock_8':
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: error: storage size of
'tzp' isn't known
/tmp/gcc/libgfortran/intrinsics/system_clock.c:130: warning: unused
variable 'tzp'
make[3]: *** [system_clock.lo] Error 1
make[3]: Leaving directory `/tmp/gcc/build/i686-pc-cygwin/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/gcc/build/i686-pc-cygwin/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/tmp/gcc/build'
make: *** [all] Error 2
The build was configured (as always):
${gcc_dir}/configure --prefix=${prefix_dir} \
--exec-prefix=${prefix_dir} \
--sysconfdir=${prefix_dir}/etc \
--libdir=${prefix_dir}/lib \
--libexecdir=${prefix_dir}/lib \
--mandir=${prefix_dir}/share/man \
--infodir=${prefix_dir}/share/info \
--enable-languages=c,fortran \
--enable-bootstrap \
--enable-decimal-float=bid \
--enable-libgomp \
--enable-threads \
--enable-sjlj-exceptions \
--enable-version-specific-runtime-libs \
--enable-nls \
--enable-checking=release \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-win32-registry \
--with-system-zlib \
--without-included-gettext \
--without-x
The Cygwin version is 1.5.25-2 (exp.).
I can confirm this. I saw it last wekend trying to do my regular cygwin build
of gfortran for the wiki. The build died and I assumed I did something wrong
and was going to try back later.
Well this is definitely a regression somewhere. Its not on the gfortran side
which has not touched that file for several months. It could be something broke
in the configure for cygwin. The error occurs in a conditional comapile:
#if defined(HAVE_SYS_TIME_H) defined(HAVE_GETTIMEOFDAY)
I will open a PR to track this.
Jerry
Jerry
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
