From: Danny S. <dan...@cl...> - 2002-08-27 05:15:23
|
This fixes the ENUMCHEK bug report. But it probably means it will limit multi-tasking programs. Jerry, what is reasonable stack-size for task. Or conversely, what it is reasonable upper limit for number of tasks. --- 5wsystem.ads.bak Sat May 04 06:19:49 2002 +++ 5wsystem.ads Tue Aug 27 05:56:42 2002 @@ -198,4 +198,8 @@ private Interrupt_Priority => 15); + pragma Linker_Options ("-Wl,--stack=0x2000000"); + --- Ada programmes are stack-hungry. + --- Bump stack size up to old value of 32 MB when linking. + end System; |
From: Danny S. <dan...@cl...> - 2002-08-27 07:17:56
|
----- Original Message ----- From: "Danny Smith" <dan...@cl...> To: "mingw-dvlpr" <min...@li...> Sent: Tuesday, 27 August 2002 06:10 Subject: [MinGW-dvlpr] Ada 3.2: Go (I think) > This fixes the ENUMCHEK bug report. But it probably means it will limit > multi-tasking programs. > Jerry, what is reasonable stack-size for task. Or conversely, what it > is reasonable upper limit for number of tasks. > Not to worry, the multi-tasking business is already done in 5wtaprop.adb, where stack set to 8 MB for multi-asking programmes. > > --- 5wsystem.ads.bak Sat May 04 06:19:49 2002 > +++ 5wsystem.ads Tue Aug 27 05:56:42 2002 > @@ -198,4 +198,8 @@ private > > Interrupt_Priority => 15); > > + pragma Linker_Options ("-Wl,--stack=0x2000000"); > + --- Ada programmes are stack-hungry. > + --- Bump stack size up to old value of 32 MB when linking. > + > end System; Also, I've just found that 3.3 branch aleady has a change (from the 'big merge', hence lacking ChangeLog documentation) to bump stack size to 32MB. I'll back that change into 3_2-cygwin-mingw-branch CVS. This change also fixes two other bug reports that Jerry submitted Danny |
From: Jerry v. D. <jv...@at...> - 2002-08-27 23:33:46
|
Danny Smith writes: > + pragma Linker_Options ("-Wl,--stack=0x2000000"); > + --- Ada programmes are stack-hungry. > + --- Bump stack size up to old value of 32 MB when linking. Yep, this makes sense... I'm going to rebuild... BTW, anyone seen this configure error before ? checking whether to enable maintainer-specific portions of Makefiles... no Links are now set up to build a native compiler for i386-pc-mingw32 updating cache ../config.cache creating ./config.status creating Makefile creating intl/Makefile creating fixinc/Makefile creating gccbug creating mklibgcc creating ada/Makefile creating auto-host.h Configuring etc... No configuration information in etc Never saw it trying to do something in etc on mingw before... -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Danny S. <dan...@cl...> - 2002-08-28 00:19:43
|
----- Original Message ----- From: "Jerry van Dijk" <jv...@at...> To: <min...@li...> Sent: Wednesday, 28 August 2002 00:33 Subject: Re: [MinGW-dvlpr] Ada 3.2: Go (I think) > > Danny Smith writes: > > > + pragma Linker_Options ("-Wl,--stack=0x2000000"); > > + --- Ada programmes are stack-hungry. > > + --- Bump stack size up to old value of 32 MB when linking. > > Yep, this makes sense... I'm going to rebuild... > I think I was too quick with that success report. I''ve since run into other sporadic problems with memory. When I use 3.3 HEAD they go away, but I don't know if it is possible to find and backport the fixes. The big merge was really a big merge and the changes are not well documented so it is difficult to pick out win32 specific ones. It might be best to be patient and spend energy getting 3.3 to work consistently. Danny > BTW, anyone seen this configure error before ? > > checking whether to enable maintainer-specific portions of Makefiles... no > Links are now set up to build a native compiler for i386-pc-mingw32 > updating cache ../config.cache > creating ./config.status > creating Makefile > creating intl/Makefile > creating fixinc/Makefile > creating gccbug > creating mklibgcc > creating ada/Makefile > creating auto-host.h > Configuring etc... > No configuration information in etc > > Never saw it trying to do something in etc on mingw before... > > -- > -- Jerry van Dijk | email: jv...@at... > -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Danny S. <dan...@cl...> - 2002-08-28 09:29:54
|
Jerry, GCC 3.3 is due out in mid Dec. The more I play with Gnat 3.2 vs 3.3 the more I'm ready to give up on Gnat 3.2. Trig math functions do not work correctly in 3.2, they do in 3.3 (with extended precison). The gnatchop in 3.3 works on everything I've tested so far (mainly examples from tutorials); the behaviour in 3.2 is very sporadic. The diff between 3.2 release and CVS HEAD in Ada source is (IMHO) too radical to attempt to backport specific fixes. So what do you think of this proposal to get some testing done on the source base that will become 3.3: Build and provide binaries of 3.3-experimental that can compile C and Ada only. This would probably have to be installed in separate tree from the 3.2 'core' because of the way gcc driver looks for language compiler. (The core gcc will look in /lib/gcc-lib/mingw32/3.2. The 3.3 Ada gcc will look in /lib/gcc-lib/mingw32/3.3. Overlaying the two may be possible, (by renaming the 3.3 gcc to GCC-3.3 and setting ADAC environment variable to GCC-3.3) but I suspect will cause confusion in long run. The binaries will be described as experimental and for bleeding edge folk only. Danny BTW I think the error you reported for the oops.ads example https://sourceforge.net/tracker/?func=detail&atid=102435&aid=560894&grou p_id=2435 may be a bug in the error reporting rather than compiler error Reading the docs gnat1 returns a non-zero status code when it cannot compile into object code. The docs also say that gnat1 will refuse to compile an .ads file on its own.: "If you attempt to compile any of these files (a package spec or subunit), you will get one of the following error messages (where fff is the name of the file you compiled): No code generated for file fff (package spec) No code generated for file fff (subunit)" That message comes with an exit status of 3, IIRC, which the gcc driver interprets as a compiler error |
From: Jerry v. D. <jv...@at...> - 2002-08-29 18:10:34
|
Danny Smith writes: > GCC 3.3 is due out in mid Dec. I've been practicing patience a lot but I am not getting any better at it :-) > Build and provide binaries of 3.3-experimental that can compile C and > Ada only. This would probably have to be installed in separate tree > from the 3.2 'core' because of the way gcc driver looks for language > compiler. (The core gcc will look in /lib/gcc-lib/mingw32/3.2. The 3.3 > Ada gcc will look in /lib/gcc-lib/mingw32/3.3. Overlaying the two may > be possible, (by renaming the 3.3 gcc to GCC-3.3 and setting ADAC > environment variable to GCC-3.3) but I suspect will cause confusion in > long run. The binaries will be described as experimental and for > bleeding edge folk only. Sounds like a good idea, altough an standalone build would be easier and result in less confusion. I'll do a checkout of 3.3 and have a go at it. BTW: the current root registry key used is still HKEY_LOCAL_MACHINE\SOFTWARE\Ada Core Technologies\GNAT I want to propose to change this for gcc to: HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GNAT What do you think ? gr. Jerry. -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Jerry v. D. <jv...@at...> - 2002-08-29 20:23:10
|
Danny Smith writes: > Build and provide binaries of 3.3-experimental There seems to be no 3.3 branch yet, so I am just co'ing gcc. Without a branch, how do I get the mingw patches ? -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Danny S. <dan...@cl...> - 2002-08-29 19:36:21
|
> Sounds like a good idea, altough an standalone build would be easier and > result in less confusion. I'll do a checkout of 3.3 and have a go at it. You'll probably need the the mingw patches to the C files in the Ada directory to get it to compile. One or two may be no longer necessary (mingw has param.h now). > > BTW: the current root registry key used is still > > HKEY_LOCAL_MACHINE\SOFTWARE\Ada Core Technologies\GNAT > > I want to propose to change this for gcc to: > > HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GNAT > > What do you think ? > Yes go for it. I suggested soemthing like that much earlier, but was booed and hissed. Since then (in trunk), however, all the source files have been changed to put FSF above ACT as far as current maintenance Danny. > gr. > Jerry. > > -- > -- Jerry van Dijk | email: jv...@at... > -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Danny S. <dan...@cl...> - 2002-08-29 20:32:17
|
----- Original Message ----- From: "Jerry van Dijk" <jv...@at...> To: <min...@li...> Sent: Thursday, 29 August 2002 21:21 Subject: Re: [MinGW-dvlpr] Gnat 3.2 vs 3.3 > > Danny Smith writes: > > > Build and provide binaries of 3.3-experimental > > There seems to be no 3.3 branch yet, so I am just co'ing gcc. Without a > branch, how do I get the mingw patches ? Sorry, your right. version-string say 3.3 but it hasn't branched yet., just co or update HEAD. I'll get a diff of my sandpit from HEAD later today ad post to list,if not too large, else to you privately. Danny > > -- > -- Jerry van Dijk | email: jv...@at... > -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ear...@ya...> - 2002-08-29 20:54:19
|
Jerry van Dijk wrote: > Danny Smith writes: > > > GCC 3.3 is due out in mid Dec. > > I've been practicing patience a lot but I am not getting any better at it :-) > > > Build and provide binaries of 3.3-experimental that can compile C and > > Ada only. This would probably have to be installed in separate tree > > from the 3.2 'core' because of the way gcc driver looks for language > > compiler. (The core gcc will look in /lib/gcc-lib/mingw32/3.2. The 3.3 > > Ada gcc will look in /lib/gcc-lib/mingw32/3.3. Overlaying the two may > > be possible, (by renaming the 3.3 gcc to GCC-3.3 and setting ADAC > > environment variable to GCC-3.3) but I suspect will cause confusion in > > long run. The binaries will be described as experimental and for > > bleeding edge folk only. > > Sounds like a good idea, altough an standalone build would be easier and > result in less confusion. I'll do a checkout of 3.3 and have a go at it. > > BTW: the current root registry key used is still > > HKEY_LOCAL_MACHINE\SOFTWARE\Ada Core Technologies\GNAT > > I want to propose to change this for gcc to: > > HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GNAT > > What do you think ? Is it really needed? I.E.: Is it decoration or is there a useful purpose? Earnie. |
From: Jerry v. D. <jv...@at...> - 2002-08-29 23:26:09
|
Earnie Boyd writes: > > HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GNAT > Is it really needed? I.E.: Is it decoration or is there a useful purpose? For GNAT, it cannot be missed. It's through the registry that GNAT, it's tools (esp. the project manager) and other Ada windows tools (GLIDE, GLADE, GtkAda, GNATCOM, ADAGIDE, GVD, etc.) locate the libraries and each other. Note that there are TWO tools to manipulate this, both called gnatreg. One comes with the ACT version of GNAT and is not included because its dependency on the Win32Ada binding, the other comes with the GWINDOWS distribution (and cannot be used as it depends on GNATCOM). I have written another version I have called gregs, but so far the GNAT binaries have not been usable enough to test it with mingw (same for the Ada version of the W32API). -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Danny S. <dan...@cl...> - 2002-08-29 22:01:59
|
> > > > BTW: the current root registry key used is still > > > > HKEY_LOCAL_MACHINE\SOFTWARE\Ada Core Technologies\GNAT > > > > I want to propose to change this for gcc to: > > > > HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GNAT > > > > What do you think ? > > Is it really needed? I.E.: Is it decoration or is there a useful purpose? > > Earnie. > It would be useful if we had a tool to manipulate the value of that key safely. It provides an alternative to setting environemnt variables. The gcc (non-Ada) has a similar key HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GCC for setting search paths for GCC. GCC has to be complied with --enable-win32-registry for that to work. Danny > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ear...@ya...> - 2002-08-29 22:16:31
|
Danny Smith wrote: > > > > > > BTW: the current root registry key used is still > > > > > > HKEY_LOCAL_MACHINE\SOFTWARE\Ada Core Technologies\GNAT > > > > > > I want to propose to change this for gcc to: > > > > > > HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GNAT > > > > > > What do you think ? > > > > Is it really needed? I.E.: Is it decoration or is there a useful > purpose? > > > > Earnie. > > > > It would be useful if we had a tool to manipulate the value of that key > safely. It provides an alternative to setting environemnt variables. > > The gcc (non-Ada) has a similar key > > HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\GCC > for setting search paths for GCC. GCC has to be complied > with --enable-win32-registry for that to work. Yes, I knew about the GCC win32-registry switch. I don't think I like it much though. Cygwin would need a different one, MinGW would need a different one, MSYS would need a different one, PW32 would need a different one, etc. I'd much rather set an environment variable. Earnie. |