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 proble
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 th
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.
---
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
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
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 cons
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://cy
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 "ex
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 hea
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
> _timez
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"
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 *
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
>> > ex
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
> > >
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
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
> > func
-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 bac
[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
>> /t
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:
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/./
20 matches
Mail list logo
