From: <dan...@ya...> - 2001-10-26 03:33:47
|
--- Thomas Pfaff <tp...@gm...> wrote: > Hi all, > > i have attached two patches to get -mthreads support working, on for > gthr-win32 in gcc, the other for the mingw 1.1 runtime. > The gthr patch is rather simple, it adds a function call to > __mingwthr_remove_key_dtor (a new function in mthr.c) to > __gthread_key_delete and changes __ghthread_key_dtor to act like the > posix > version. It seems that __gthread_key_delete is never called but i have > included it anyway. > > The Changelog for this would be: > > 2001-10-16 Thomas Pfaff <tp...@gm...> > * gthr-win32.h (__gthread_key_dtor) Let it act like the posix > version in gthr-posix.h > (__ghthread_key_delete) Call __mingwthr_remove_key_dtor to remove > the key from the key/dtor list > > The mthr stuff in the mingw runtime is a complete rewrite. Mumit has > written the key/dtor code to be thread dependend. I think this was a > mistake and it has lead to memory leaks in the mthreads support. Only the > first dying thread will have its additional memory for Exception > handling freed. > > The Changelog for the mingw runtime would be: > > 2001-10-16 Thomas Pfaff <tp...@gm...> > * mthr_stub.c (__mingwthr_remove_key_dtor) New > * mthr_init.c (DllMain) Run dtors if a process terminates > * mthr.c (__mingwthr_add_key_dtor) Removed > (___mingwthr_add_key_dtor) New > (___mingwthr_remove_key_dtor) New > (__mingwthr_run_key_dtors) Complete rewrite > (__mingwthr_remove_key_dtor) New > > With the new code i have no more memory leaks when threads are > terminating > even if i create threads continuously and wait for their completion. > > The new code in mingwm10.dll would be upward compatible so there is no > need to rename the dll. > > Comments are very welcome. > > Greetings, > > Thomas > > ATTACHMENT part 2 application/octet-stream name=gthr.patch.gz > ATTACHMENT part 3 application/octet-stream name=mingwruntime.patch.gz Thomas. I think this is excellent and unless I hear any objections from other mingw developers I will commit to mingw runtime cvs. I have tested on gcc 3.0.2 and trunk GCC CVS, as well as 2.95.3 and have seen no problems. Thomas, do you want to submit a patch for gthr-win32.h to CGG-patches. It will need to be updated slightly because now gthr-win32.h is included by G++-v3 header stl-threads.h, so the two extern functions need to wrapped in extern "C". I also took out the PARAMS since those macros aren't normally defined when using C++ headers Here is my diff. I've put in a forward declaration of __gthread_setspecific to avoid having to rearrange functions (it makes the diff smaller, and thus more likely to be accepted.) Also, the stl threads seems to work well enough without the gthreads abstraction layer, but I've commented that change out since I haven't tested enough. Index: gthr-win32.h =================================================================== RCS file: /cvs/gcc/gcc/gcc/gthr-win32.h,v retrieving revision 1.8 diff -u -p -r1.8 gthr-win32.h --- gthr-win32.h 2001/01/22 21:29:53 1.8 +++ gthr-win32.h 2001/10/26 03:23:13 @@ -63,6 +63,8 @@ Boston, MA 02111-1307, USA. */ needs to use Structured Exception Handling on Windows32. */ #define __GTHREADS 1 + /* #undef __STL_GTHREADS */ + /* #define __STL_WIN32THREADS 1 */ #include <windows.h> #include <errno.h> @@ -320,10 +322,6 @@ __gthread_objc_condition_signal(objc_con #else /* _LIBOBJC */ -#ifdef __MINGW32__ -#include <_mingw.h> -#endif - typedef DWORD __gthread_key_t; typedef struct { @@ -339,7 +337,14 @@ typedef HANDLE __gthread_mutex_t; #if __MINGW32_MAJOR_VERSION >= 1 || \ (__MINGW32_MAJOR_VERSION == 0 && __MINGW32_MINOR_VERSION > 2) #define MINGW32_SUPPORTS_MT_EH 1 -extern int __mingwthr_key_dtor PARAMS ((DWORD, void (*) (void *))); +#ifdef __cplusplus +extern "C" { +#endif +extern int __mingwthr_key_dtor (DWORD, void (*) (void *)); +extern int __mingwthr_remove_key_dtor (DWORD); +#ifdef __cplusplus +} +#endif /* Mingw runtime >= v0.3 provides a magic variable that is set to non-zero if -mthreads option was specified, or 0 otherwise. This is to get around the lack of weak symbols in PE-COFF. */ @@ -410,16 +415,26 @@ __gthread_key_create (__gthread_key_t *k /* Currently, this routine is called only for Mingw runtime, and if -mthreads option is chosen to link in the thread support DLL. */ + static inline int -__gthread_key_dtor (__gthread_key_t key, void *ptr) -{ - /* Nothing needed. */ - return 0; -} +__gthread_setspecific (__gthread_key_t key, const void *ptr); static inline int +__gthread_key_dtor (__gthread_key_t key, void *ptr) + { + /* Just reset the key value to zero. */ + if (ptr) + return __gthread_setspecific(key, 0); + else + return 0; /* Nothing needed. */ +} + + static inline int __gthread_key_delete (__gthread_key_t key) { +#ifdef MINGW32_SUPPORTS_MT_EH + __mingwthr_remove_key_dtor(key); +#endif return (TlsFree (key) != 0) ? 0 : (int) GetLastError (); } http://briefcase.yahoo.com.au - Yahoo! Briefcase - Manage your files online. |
From: Thomas P. <tp...@gm...> - 2001-10-26 08:31:50
Attachments:
mthr.patch.gz
|
On Fri, 26 Oct 2001, Danny Smith wrote: > --- Thomas Pfaff <tp...@gm...> wrote: > Hi all, > > > > The mthr stuff in the mingw runtime is a complete rewrite. Mumit has > > written the key/dtor code to be thread dependend. I think this was a > > mistake and it has lead to memory leaks in the mthreads support. Only the > > first dying thread will have its additional memory for Exception > > handling freed. > > > > The Changelog for the mingw runtime would be: > > > > 2001-10-16 Thomas Pfaff <tp...@gm...> > > * mthr_stub.c (__mingwthr_remove_key_dtor) New > > * mthr_init.c (DllMain) Run dtors if a process terminates > > * mthr.c (__mingwthr_add_key_dtor) Removed > > (___mingwthr_add_key_dtor) New > > (___mingwthr_remove_key_dtor) New > > (__mingwthr_run_key_dtors) Complete rewrite > > (__mingwthr_remove_key_dtor) New > > Sorry, but i have found a big bug in the __mingwthr_run_key_dtors code (patch is attached). 2001-10-26 Thomas Pfaff <tp...@gm...> (__mingwthr_run_key_dtors) Removed free of key memory I do not know how this could ever run in my tests, it seems that this is just another MS VM wonder. > Thomas. I think this is excellent and unless I hear any objections from > other mingw developers I will commit to mingw runtime cvs. I have tested > on gcc 3.0.2 and trunk GCC CVS, as well as 2.95.3 and have seen no > problems. Thomas, do you want to submit a patch for gthr-win32.h to > CGG-patches. It will need to be updated slightly because now gthr-win32.h > is included by G++-v3 header stl-threads.h, so the two extern functions > need to wrapped in extern "C". I also took out the PARAMS since those > macros aren't normally defined when using C++ headers Would you please submit the patch ? I currently do not have a working CVS access to the GCC repository (at work i am sitting behind a firewall that blocks CVS, my home line is simply to slow). Greetings, Thomas |
From: <dan...@ya...> - 2002-04-25 08:00:50
|
This is a refresh of an earlier patch, It hasn't changed substantially, except for addition of fflush to the clean-up proc. I wish to apply to both mingw trunk and mingwex branch. atexit currently does not work when called from a dll. dllcrt1.c includes a dummy atexit to ensure that it doesn't cause serious problems, but it doesn't help if we really want to call atext/_onexit from dll. The atexit-registered functions in the dll are simply ignored. The attached patch fixes by: 1) Only export atexit from libmsvcrt.a as _imp__atexit. Do this by pretending its DATA. Do same for _onexit, just in case users want this one instead of atexit. Do same in crtdll.def. 2) When building *.exe, link atexit aginst the one in msvcrt.dll. This is done by defining atexit in crt1.c as a thunk for _imp__atexit 3) When building *.dll, initialise a private atexit table at startup. Fill it up with registered functions by making atexit a wrapper for the __dllonexit function exported from msvcrt.dll. Unlike atexit, __dllonexit takes arguments specify the head and tail of the table. When detaching from dll, we run the functions registered in this private table. Oh yeah, when detaching always fflush the output buffers, otherwise output of DllMain::DLL_PROCESS_DETACH *and* of atexit-registered functions get lost when redirecting output. Here is the diff: ChangeLog 2002-04-25 Danny Smith <dan...@us...> * crt1.c (atexit): New function. Force thunk to _imp__atexit. (_onexit): New function. Force thunk to _imp___onexit. * dllcrt1.c (DllMainCRTStartup): Initialise private atexit table on DLL_PROCESS_ATTACH, clean it up on DLL_PROCESS_DETACH. (__dll_exit): New function to run private atexit-registered functions and flush output buffers on DLL_PROCESS_DETACH or failed DLL_PROCESS_ATTACH. (atexit): Force use of private atexit table via _dllonexit, (_onexit): New function. Force use of private atexit table via _dllonexit, * mscvrt.def (atexit, _onexit): Add DATA keyword so that only _imp_<_symbol> is visible in import lib. * mscvrt20.def: Likewise. * mscvrt40.def: Likewise. * crtdll.def: Likewise. Index: crt1.c =================================================================== RCS file: /cvs/src/src/winsup/mingw/crt1.c,v retrieving revision 1.1.1.1.40.2 diff -u -p -r1.1.1.1.40.2 crt1.c --- crt1.c 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.2 +++ crt1.c 25 Apr 2002 04:42:18 -0000 @@ -232,3 +233,20 @@ WinMainCRTStartup () __mingw_CRTStartup (); } +/* + * We force use of library version of atexit, which is only + * visible in import lib as _imp__atexit + */ +extern int (*_imp__atexit)(void (*)(void)); +int atexit (void (* pfn )(void) ) +{ + return ( (*_imp__atexit)(pfn)); +} + +/* Likewise for non-ANSI _onexit */ +extern _onexit_t (*_imp___onexit)(_onexit_t); +_onexit_t +_onexit (_onexit_t pfn ) +{ + return (*_imp___onexit)(pfn); +} Index: crtdll.def =================================================================== RCS file: /cvs/src/src/winsup/mingw/crtdll.def,v retrieving revision 1.1.1.1.40.1 diff -u -p -r1.1.1.1.40.1 crtdll.def --- crtdll.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 +++ crtdll.def 25 Apr 2002 04:42:22 -0000 @@ -414,7 +414,7 @@ _mkdir _mktemp _msize _nextafter -_onexit +_onexit DATA _open _open_osfhandle _osmajor_dll DATA @@ -520,7 +520,7 @@ asctime asin atan atan2 -atexit +atexit DATA atof atoi atol Index: dllcrt1.c =================================================================== RCS file: /cvs/src/src/winsup/mingw/dllcrt1.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 dllcrt1.c --- dllcrt1.c 17 Feb 2000 19:38:31 -0000 1.1.1.1 +++ dllcrt1.c 25 Apr 2002 04:42:22 -0000 @@ -20,15 +20,16 @@ * DISCLAMED. This includes but is not limited to warrenties of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * - * $Revision: 1.4 $ - * $Author: cgf $ - * $Date: 2000/02/05 04:04:42 $ + * $Revision: 1.2 $ + * $Author: earnie $ + * $Date: 2001/06/05 00:26:30 $ * */ - +#include <stdlib.h> #include <stdio.h> #include <io.h> #include <process.h> +#include <errno.h> #include <windows.h> /* Unlike normal crt1, I don't initialize the FPU, because the process @@ -40,50 +41,156 @@ extern void __main (); extern void __do_global_dtors (); #endif +typedef void (* p_atexit_fn )(void); +static p_atexit_fn* first_atexit; +static p_atexit_fn* next_atexit; + +static void +__dll_exit (void); + +/* This is based on the function in the Wine project's exit.c */ +p_atexit_fn __dllonexit (p_atexit_fn, p_atexit_fn**, p_atexit_fn**); + + extern BOOL WINAPI DllMain (HANDLE, DWORD, LPVOID); + BOOL WINAPI DllMainCRTStartup (HANDLE hDll, DWORD dwReason, LPVOID lpReserved) { BOOL bRet; if (dwReason == DLL_PROCESS_ATTACH) { + /* Initialize private atexit table for this dll. + 32 is min size required by ANSI */ + + first_atexit = (p_atexit_fn*) malloc (32 * sizeof (p_atexit_fn)); + if (first_atexit == NULL ) /* can't allocate memory */ + { + errno=ENOMEM; + return FALSE; + } + *first_atexit = NULL; + next_atexit = first_atexit; + +#ifdef DEBUG + printf ("%s: DLL_PROCESS_ATTACH (%d)\n", __FUNCTION__); +#endif + + #ifdef __GNUC__ - /* From libgcc.a, calls global class constructors. */ + /* From libgcc.a, __main calls global class constructors, + __do_global_ctors, which registers __do_global_dtors + as the first entry of the private atexit table we + have just initialised */ __main (); + #endif - } + } /* - * Call the user-supplied DllMain subroutine + * Call the user-supplied DllMain subroutine. + * This has to come after initialization of atexit table and + * registration of global constructors. * NOTE: DllMain is optional, so libmingw32.a includes a stub * which will be used if the user does not supply one. */ + bRet = DllMain (hDll, dwReason, lpReserved); + /* Handle case where DllMain returns FALSE on attachment attempt. */ -#ifdef __GNUC__ - if (dwReason == DLL_PROCESS_DETACH) + if ((dwReason == DLL_PROCESS_ATTACH) && !bRet) { - /* From libgcc.a, calls global class destructors. */ - __do_global_dtors (); - } +#ifdef DEBUG + printf ("%s: DLL_PROCESS_ATTACH failed, cleaning up\n", __FUNCTION__); #endif + __dll_exit (); /* Cleanup now. This will reset first_atexit to NULL + so we know we've cleaned up */ + } + + if (dwReason == DLL_PROCESS_DETACH) + { +#ifdef DEBUG + printf ("%s: DLL_PROCESS_DETACH (%d)\n", __FUNCTION__); +#endif + /* If not attached, return FALSE. Cleanup already done above + if failed attachment attempt. */ + if (! first_atexit ) + bRet = FALSE; + else + /* + * We used to call __do_global_dtors () here. This is + * no longer necessary since __do_global_dtors is now + * registered at start (last out) of private atexit table. + */ + __dll_exit (); + } return bRet; } +static +void +__dll_exit(void) +/* Run LIFO terminators registered in private atexit table */ +{ + if ( first_atexit ) + { + p_atexit_fn* __last = next_atexit - 1; + while ( __last >= first_atexit ) + { + if ( *__last != NULL ) + { +#ifdef DEBUG + printf ("%s: Calling exit function 0x%x from 0x%x\n", + __FUNCTION__, (unsigned)(*__last),(unsigned)__last); +#endif + (**__last) (); + } + __last--; + } + free ( first_atexit ) ; + first_atexit = NULL ; + } + /* + Make sure output buffers opened by DllMain or + atexit-registered functions are flushed before detaching, + otherwise we can have problems with redirected output. + */ + fflush (NULL); +} + /* - * For the moment a dummy atexit. Atexit causes problems in DLLs, especially - * if they are dynamically loaded. For now atexit inside a DLL does nothing. - * NOTE: We need this even if the DLL author never calls atexit because - * the global constructor function __do_global_ctors called from __main - * will attempt to register __do_global_dtors using atexit. - * Thanks to Andrey A. Smirnov for pointing this one out. + * The atexit exported from msvcrt.dll causes problems in DLLs. + * Here, we override the exported version of atexit with one that passes the + * private table initialised in DllMainCRTStartup to __dllonexit. + * That means we have to hide the mscvrt.dll atexit because the + * atexit defined here gets __dllonexit from the same lib. */ + int -atexit (void (*pfn) ()) +atexit (p_atexit_fn pfn ) { - return 0; +#ifdef DEBUG + printf ("%s: registering exit function 0x%x at 0x%x\n", + __FUNCTION__, (unsigned)pfn, (unsigned)next_atexit); +#endif + return (__dllonexit (pfn, &first_atexit, &next_atexit) + == NULL ? -1 : 0 ); } +/* + * Likewise for non-ANSI function _onexit that may be called by + * code in the dll. + */ + +_onexit_t +_onexit (_onexit_t pfn ) +{ +#ifdef DEBUG + printf ("%s: registering exit function 0x%x at 0x%x\n", + __FUNCTION__, (unsigned)pfn, (unsigned)next_atexit); +#endif + return ((_onexit_t) __dllonexit ((p_atexit_fn)pfn, &first_atexit, &next_atexit)); +} Index: msvcrt.def =================================================================== RCS file: /cvs/src/src/winsup/mingw/msvcrt.def,v retrieving revision 1.1.1.1.40.1 diff -u -p -r1.1.1.1.40.1 msvcrt.def --- msvcrt.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 +++ msvcrt.def 25 Apr 2002 04:42:22 -0000 @@ -365,7 +365,7 @@ _mkdir _mktemp _msize _nextafter -_onexit +_onexit DATA _open _open_osfhandle _osver DATA @@ -546,7 +546,7 @@ asctime asin atan atan2 -atexit +atexit DATA atof atoi atol Index: msvcrt20.def =================================================================== RCS file: /cvs/src/src/winsup/mingw/msvcrt20.def,v retrieving revision 1.1.1.1.40.1 diff -u -p -r1.1.1.1.40.1 msvcrt20.def --- msvcrt20.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 +++ msvcrt20.def 25 Apr 2002 04:42:22 -0000 @@ -329,7 +329,7 @@ _msize _mtlock _mtunlock _nextafter -_onexit +_onexit DATA _open _open_osfhandle _osver @@ -528,7 +528,7 @@ asctime asin atan atan2 -atexit +atexit DATA atof atoi atol Index: msvcrt40.def =================================================================== RCS file: /cvs/src/src/winsup/mingw/msvcrt40.def,v retrieving revision 1.1.1.1.40.1 diff -u -p -r1.1.1.1.40.1 msvcrt40.def --- msvcrt40.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 +++ msvcrt40.def 25 Apr 2002 04:42:25 -0000 @@ -312,7 +312,7 @@ _msize _mtlock _mtunlock _nextafter -_onexit +_onexit DATA _open _open_osfhandle _osver @@ -485,7 +485,7 @@ asctime asin atan atan2 -atexit +atexit DATA atof atoi atol http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! |
From: <dan...@ya...> - 2002-04-25 09:35:46
|
I am just about ready to roll GCC 3.1 into a beat release for mingw next week but need advice on packaging details. Here is my tentative plan. Please correct/augment/prune if deficient or excessive: 1) Core release: C, C++,Fortran, ObjC. Plus runtime libs. No shared runtime libs (dlls) at this stage. 2) Extra: Gnat Ada compiler + libs (the gcc.exe driver in core will recognize Ada as a supported language but won't be able to do anything without this add-on). There are known bugs in this relative to ACT's 3.14 release (based on gcc 2.8.1) but AFAICT are limited to ACT's GTKAda, GLADE, and other ACT "products". 3) Info files in binary dists above. HTML versions in separate package. 4) source packaging follow 1,2. Most of my testing has been done using mingwex branch (and its precursor in my sandpit) of runtime, but those extensions are not necessary. Should I put libmingwex.a as system lib in specs? Should I make IEEE extended reals (64 bit mantissa) as default like the rest of the i386 world or stick with the MSVC way? These are the additions/patches to mingw not yet in official sources: 1) Mumit's tweaks for C+++ dllimport. 2) Fastcall support (Eric Kohl and ReactOs friends, fiends and allies). 3) --mms-bitfield-layout: The new-look replacement for -fnative-struct. 4) C++ numeric_limits definitions for NaNs, denorm_min etc. 5) Return of structs <= 64 bits in registers (eg ldiv). If I get A into G some of these might make it by 3.3 ( I like odd numbers). There are known deficiencies in C++ wrt wide char, locales. I have avoided testing complex long double math in C++, so expect bugs there as well. I think that's it. Any comment appreciated. Except one: Don't ask me for Java yet Danny http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! |
From: Earnie B. <ear...@ya...> - 2002-04-25 11:25:52
|
Danny Smith wrote: > > I am just about ready to roll GCC 3.1 into a beat release for mingw next week > but need advice on packaging details. Here is my tentative plan. Please > correct/augment/prune if deficient or excessive: > Good timing for discussing packaging. I've grown to like INNO Setup and think you should have a go with packaging MinGW-2.0 with it. I cvs added my .iss script for msys yesterday to msys/dvlpr so you could use that for a template. It must be in \r\n format for the setup command line tool :(. > 1) Core release: C, C++,Fortran, ObjC. Plus runtime libs. No shared runtime > libs (dlls) at this stage. You might want to add GPC (GNU Pascal Compiler), it builds without fuss. > 2) Extra: Gnat Ada compiler + libs (the gcc.exe driver in core will recognize > Ada as a supported language but won't be able to do anything without this > add-on). There are known bugs in this relative to ACT's 3.14 release (based on > gcc 2.8.1) but AFAICT are limited to ACT's GTKAda, GLADE, and other ACT > "products". How big is this one? > 3) Info files in binary dists above. HTML versions in separate package. I would prefer all doco in a separate INNO Setup distribution. You could allow the user the choice of all, info or html. > 4) source packaging follow 1,2. > By follow, you mean a separate package for the source for each of 1 and 2 above? > Most of my testing has been done using mingwex branch (and its precursor in my > sandpit) of runtime, but those extensions are not necessary. Should I put > libmingwex.a as system lib in specs? Should I make IEEE extended reals (64 bit > mantissa) as default like the rest of the i386 world or stick with the MSVC > way? > Do you have mingwex ready for production? If so, merge your branch to head and go for it. Use the IEEE extended reals. > These are the additions/patches to mingw not yet in official sources: > > 1) Mumit's tweaks for C+++ dllimport. > 2) Fastcall support (Eric Kohl and ReactOs friends, fiends and allies). > 3) --mms-bitfield-layout: The new-look replacement for -fnative-struct. > 4) C++ numeric_limits definitions for NaNs, denorm_min etc. > 5) Return of structs <= 64 bits in registers (eg ldiv). > I'm of the belief that you should upload the GCC pristine source for a release tagged as sv0 (sv = subversion), then commit your initial changes and rtag as sv1. Then with each subsequent release rtag as sv2, etc. I like a directory structure for this similar to gcc/2.95.3, gcc/3.1, etc. but gcc-2.95.3, gcc-3.1, etc. works as well. > If I get A into G some of these might make it by 3.3 ( I like odd numbers). > This would be good. > There are known deficiencies in C++ wrt wide char, locales. You can document these easily in the INNO Setup presentation. > I have avoided testing complex long double math in C++, so expect bugs there as > > well. > > I think that's it. > > Any comment appreciated. Except one: Don't ask me for Java yet > Ok, when is MinGW going to release a Java compiler? ;) Earnie. |
From: <dan...@ya...> - 2002-04-25 12:03:19
|
--- Earnie Boyd <ear...@ya...> wrote: > Danny Smith wrote: > > > > I am just about ready to roll GCC 3.1 into a beat release for mingw next ^^^^ beta > week > > but need advice on packaging details. Here is my tentative plan. Please > > correct/augment/prune if deficient or excessive: > > > > Good timing for discussing packaging. I've grown to like INNO Setup and > think you should have a go with packaging MinGW-2.0 with it. I cvs > added my .iss script for msys yesterday to msys/dvlpr so you could use > that for a template. It must be in \r\n format for the setup command > line tool :(. > Please remember this is a beta (aka beat) for testing. I don't have a lot of bandwith for experimenting with setup progs right now. Maybe when the production 2.0 is ready. > > 1) Core release: C, C++,Fortran, ObjC. Plus runtime libs. No shared > runtime > > libs (dlls) at this stage. > > You might want to add GPC (GNU Pascal Compiler), it builds without fuss. I'll look. > > 2) Extra: Gnat Ada compiler + libs (the gcc.exe driver in core will > recognize > > Ada as a supported language but won't be able to do anything without this > > add-on). There are known bugs in this relative to ACT's 3.14 release > (based on > > gcc 2.8.1) but AFAICT are limited to ACT's GTKAda, GLADE, and other ACT > > "products". > > How big is this one? Huge. I haven't split out yet since when I build I do the whole frigging lot, starting with runtime, binutils, bootstrap gcc, all the way to libstc++.a and gnatdll.exe. I'd guess about 16 MB uncompressed. > > > 3) Info files in binary dists above. HTML versions in separate package. > > I would prefer all doco in a separate INNO Setup distribution. You > could allow the user the choice of all, info or html. > Again this a beta for testing. Info files get built/installed automatically. Adding html requires a trivial second step. I'll look at INNO later. > > 4) source packaging follow 1,2. > > > > By follow, you mean a separate package for the source for each of 1 and > 2 above? Yes. The Ada source is big and can be split out fairly cleanly from the rest. My guess is that only a few people will want Ada. > > > Most of my testing has been done using mingwex branch (and its precursor in > my > > sandpit) of runtime, but those extensions are not necessary. Should I put > > libmingwex.a as system lib in specs? Should I make IEEE extended reals (64 > bit > > mantissa) as default like the rest of the i386 world or stick with the MSVC > > way? > > > > Do you have mingwex ready for production? If so, merge your branch to > head and go for it. Use the IEEE extended reals. Okay. > > > These are the additions/patches to mingw not yet in official sources: > > > > 1) Mumit's tweaks for C+++ dllimport. > > 2) Fastcall support (Eric Kohl and ReactOs friends, fiends and allies). > > 3) --mms-bitfield-layout: The new-look replacement for -fnative-struct. > > 4) C++ numeric_limits definitions for NaNs, denorm_min etc. > > 5) Return of structs <= 64 bits in registers (eg ldiv). > > > > I'm of the belief that you should upload the GCC pristine source for a > release tagged as sv0 (sv = subversion), then commit your initial > changes and rtag as sv1. Then with each subsequent release rtag as sv2, > etc. I like a directory structure for this similar to gcc/2.95.3, > gcc/3.1, etc. but gcc-2.95.3, gcc-3.1, etc. works as well. > I don't have cycles for all that right now. If you want that from me, you might get it by end of May. I can roll out binaries and archived source and diffs next week. > > If I get A into G some of these might make it by 3.3 ( I like odd > numbers). > > > > This would be good. > > > There are known deficiencies in C++ wrt wide char, locales. > > You can document these easily in the INNO Setup presentation. > > > I have avoided testing complex long double math in C++, so expect bugs > there as > > > > well. > > > > I think that's it. > > > > Any comment appreciated. Except one: Don't ask me for Java yet > > > > Ok, when is MinGW going to release a Java compiler? ;) 1) When windows has case-sensitive filenames. or 2) When someone else does it. > > Earnie. > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! |
From: Earnie B. <ear...@ya...> - 2002-04-25 12:41:57
|
Danny Smith wrote: > > --- Earnie Boyd <ear...@ya...> wrote: > Danny Smith wrote: > > > > > > I am just about ready to roll GCC 3.1 into a beat release for mingw next > ^^^^ > beta > > week > > > > but need advice on packaging details. Here is my tentative plan. Please > > > correct/augment/prune if deficient or excessive: > > > > > > > Good timing for discussing packaging. I've grown to like INNO Setup and > > think you should have a go with packaging MinGW-2.0 with it. I cvs > > added my .iss script for msys yesterday to msys/dvlpr so you could use > > that for a template. It must be in \r\n format for the setup command > > line tool :(. > > > > Please remember this is a beta (aka beat) for testing. I don't have a lot of > bandwith for experimenting with setup progs right now. Maybe when the > production 2.0 is ready. Ok. > > > > 2) Extra: Gnat Ada compiler + libs (the gcc.exe driver in core will > > recognize > > > Ada as a supported language but won't be able to do anything without this > > > add-on). There are known bugs in this relative to ACT's 3.14 release > > (based on > > > gcc 2.8.1) but AFAICT are limited to ACT's GTKAda, GLADE, and other ACT > > > "products". > > > > How big is this one? > > Huge. I haven't split out yet since when I build I do the whole frigging lot, > starting with runtime, binutils, bootstrap gcc, all the way to libstc++.a and > gnatdll.exe. I'd guess about 16 MB uncompressed. Yep, that warrants an extra package. Perhaps a name of mingwADA or MinGWada. > > > > > 3) Info files in binary dists above. HTML versions in separate package. > > > > I would prefer all doco in a separate INNO Setup distribution. You > > could allow the user the choice of all, info or html. > > > Again this a beta for testing. Info files get built/installed automatically. > Adding html requires a trivial second step. I'll look at INNO later. > Ok, INNO isn't that difficult though even for betas. I took the time to document my .iss script and INNO has a decent help file. > > > > > These are the additions/patches to mingw not yet in official sources: > > > > > > 1) Mumit's tweaks for C+++ dllimport. > > > 2) Fastcall support (Eric Kohl and ReactOs friends, fiends and allies). > > > 3) --mms-bitfield-layout: The new-look replacement for -fnative-struct. > > > 4) C++ numeric_limits definitions for NaNs, denorm_min etc. > > > 5) Return of structs <= 64 bits in registers (eg ldiv). > > > > > > > I'm of the belief that you should upload the GCC pristine source for a > > release tagged as sv0 (sv = subversion), then commit your initial > > changes and rtag as sv1. Then with each subsequent release rtag as sv2, > > etc. I like a directory structure for this similar to gcc/2.95.3, > > gcc/3.1, etc. but gcc-2.95.3, gcc-3.1, etc. works as well. > > > > I don't have cycles for all that right now. If you want that from me, you might > get it by end of May. I can roll out binaries and archived source and diffs > next week. > Oh, I forgot you don't have the bandwidth I do. Yea, that would take you some time. > > > If I get A into G some of these might make it by 3.3 ( I like odd > > numbers). > > > > > > > This would be good. > > > > > There are known deficiencies in C++ wrt wide char, locales. > > > > You can document these easily in the INNO Setup presentation. > > > > > > I have avoided testing complex long double math in C++, so expect bugs > > there as > > > > > > well. > > > > > > I think that's it. > > > > > > Any comment appreciated. Except one: Don't ask me for Java yet > > > > > > > Ok, when is MinGW going to release a Java compiler? ;) > > 1) When windows has case-sensitive filenames. > or > 2) When someone else does it. > I like option 1. LOL. Earnie. |
From: Luke D. <cod...@ho...> - 2002-04-26 01:28:12
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: "Danny Smith" <dan...@ya...> Cc: "mingw-dvlpr" <min...@li...> Sent: Thursday, April 25, 2002 7:24 PM Subject: Re: [MinGW-dvlpr] GCC 3.1 > Danny Smith wrote: > > > > I am just about ready to roll GCC 3.1 into a beat release for mingw next week > > but need advice on packaging details. Here is my tentative plan. Please > > correct/augment/prune if deficient or excessive: > > > > Good timing for discussing packaging. I've grown to like INNO Setup and > think you should have a go with packaging MinGW-2.0 with it. I cvs > added my .iss script for msys yesterday to msys/dvlpr so you could use > that for a template. It must be in \r\n format for the setup command > line tool :(. > Using an automated installer for all components of Mingw (eventually) would be a nice improvement. Of course you will probably still want to provide the source in tar.gz files so that it can be used with Unix/Linux too. > > 1) Core release: C, C++,Fortran, ObjC. Plus runtime libs. No shared runtime > > libs (dlls) at this stage. > > You might want to add GPC (GNU Pascal Compiler), it builds without fuss. Do you know how many people use Fortran and Objective C? Maybe it would be too much hassle, but I think that having these languages (with Pascal/Ada) in a separate package would be more convenient for the majority of users, particularly those that have slow connections. When shared libraries are available, I think it would be better to dynamically link to libgcc by default (at least for C++), so that exceptions+DLLs always work, and to have the option of a libstdc++ DLL. > > > 2) Extra: Gnat Ada compiler + libs (the gcc.exe driver in core will recognize > > Ada as a supported language but won't be able to do anything without this > > add-on). There are known bugs in this relative to ACT's 3.14 release (based on > > gcc 2.8.1) but AFAICT are limited to ACT's GTKAda, GLADE, and other ACT > > "products". > > How big is this one? > > > 3) Info files in binary dists above. HTML versions in separate package. > > I would prefer all doco in a separate INNO Setup distribution. You > could allow the user the choice of all, info or html. Yes, I don't really see why info documentation should be included with the binaries, since I don't know of any Mingw (or MSYS) port of the info viewer. I think html documentation would be accessible to many more users, but to be even more user-friendly it would be great to also have compiled HTML help documentation. Jose's page at http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/documentation/chm/index.html gives instructions for producing CHM files using the MS HTML Help SDK. Having documentation that Windows users can easily access (preferably through Start menu shortcuts) and search would also reduce the number of questions people need to ask. Luke Dunstan |
From: <dan...@ya...> - 2002-04-26 01:51:00
|
--- Luke Dunstan <cod...@ho...> wrote: > > ----- Original Message ----- > From: "Earnie Boyd" <ear...@ya...> > To: "Danny Smith" <dan...@ya...> > Cc: "mingw-dvlpr" <min...@li...> > Sent: Thursday, April 25, 2002 7:24 PM > Subject: Re: [MinGW-dvlpr] GCC 3.1 > > > > Danny Smith wrote: > > > > > > I am just about ready to roll GCC 3.1 into a beat release for mingw > next week > > > but need advice on packaging details. Here is my tentative plan. > Please > > > correct/augment/prune if deficient or excessive: > > > > > > > Good timing for discussing packaging. I've grown to like INNO Setup and > > think you should have a go with packaging MinGW-2.0 with it. I cvs > > added my .iss script for msys yesterday to msys/dvlpr so you could use > > that for a template. It must be in \r\n format for the setup command > > line tool :(. > > > > Using an automated installer for all components of Mingw (eventually) would > be a nice improvement. Of course you will probably still want to provide the > source in tar.gz files so that it can be used with Unix/Linux too. > > > > 1) Core release: C, C++,Fortran, ObjC. Plus runtime libs. No shared > runtime > > > libs (dlls) at this stage. > > > > You might want to add GPC (GNU Pascal Compiler), it builds without fuss. GPC does not come with standard FSF GCC package. If there is any demand I'll see if can be integrated into GCC driver. > > Do you know how many people use Fortran Me for one. and Objective C? Maybe it would be> too much hassle, but I think that having these languages (with Pascal/Ada)> in a separate package would be more convenient for the majority of users, > particularly those that have slow connections. I have a slow connection and it is more convenient for me to leave the bundle as it is packaged by GCC configury. Having separate binary packages implies (to me) having separate source packages. When shared libraries are > available, I think it would be better to dynamically link to libgcc by > default (at least for C++), so that exceptions+DLLs always work, and to have > the option of a libstdc++ DLL. That is a possible future development. I have tested a libsupc++.dll (where exception handling lives) and seems okay, but lets not introduce too many bugs until 3.1 stabilizes a bit. Are you sure you want to distribute a 1 MB libstdc++.dll with all your apps just to have iostreams? > > > > > > 2) Extra: Gnat Ada compiler + libs (the gcc.exe driver in core will > recognize > > > Ada as a supported language but won't be able to do anything without > this > > > add-on). There are known bugs in this relative to ACT's 3.14 release > (based on > > > gcc 2.8.1) but AFAICT are limited to ACT's GTKAda, GLADE, and other ACT > > > "products". > > > > How big is this one? > > > > > 3) Info files in binary dists above. HTML versions in separate package. > > > > I would prefer all doco in a separate INNO Setup distribution. You > > could allow the user the choice of all, info or html. > > Yes, I don't really see why info documentation should be included with the > binaries, since I don't know of any Mingw (or MSYS) port of the info viewer. > I think html documentation would be accessible to many more users, but to be > even more user-friendly it would be great to also have compiled HTML help > documentation. Jose's page at > http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/documentation/chm/index.html > gives instructions for producing CHM files using the MS HTML Help SDK. > Having documentation that Windows users can easily access (preferably > through Start menu shortcuts) and search would also reduce the number of > questions people need to ask. > One day. > Luke Dunstan > > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! |
From: Earnie B. <ear...@ya...> - 2002-04-25 11:00:53
|
Go for it, it has my approval. Earnie. Danny Smith wrote: > > This is a refresh of an earlier patch, It hasn't changed substantially, > except for addition of fflush to the clean-up proc. > > I wish to apply to both mingw trunk and mingwex branch. > > atexit currently does not work when called from a dll. > dllcrt1.c includes a dummy atexit to ensure that it doesn't cause serious > problems, but it doesn't help if we really want to call atext/_onexit > from dll. > The atexit-registered functions in the dll are simply ignored. > > The attached patch fixes by: > > 1) Only export atexit from libmsvcrt.a as _imp__atexit. Do this > by pretending its DATA. Do same for _onexit, just in case users want > this one instead of atexit. Do same in crtdll.def. > > 2) When building *.exe, link atexit aginst the one in msvcrt.dll. This > is done by defining atexit in crt1.c as a thunk for _imp__atexit > > 3) When building *.dll, initialise a private atexit table at startup. > Fill it up with registered functions by making atexit a wrapper for the > __dllonexit function exported from msvcrt.dll. Unlike atexit, __dllonexit > takes arguments specify the head and tail of the table. When detaching from > dll, we run the functions registered in this private table. > > Oh yeah, when detaching always fflush the output buffers, otherwise > output of DllMain::DLL_PROCESS_DETACH *and* of atexit-registered > functions get lost when redirecting output. > > Here is the diff: > > ChangeLog > > 2002-04-25 Danny Smith <dan...@us...> > > * crt1.c (atexit): New function. Force thunk to _imp__atexit. > (_onexit): New function. Force thunk to _imp___onexit. > * dllcrt1.c (DllMainCRTStartup): Initialise private atexit > table on DLL_PROCESS_ATTACH, clean it up on DLL_PROCESS_DETACH. > (__dll_exit): New function to run private atexit-registered > functions and flush output buffers on DLL_PROCESS_DETACH or > failed DLL_PROCESS_ATTACH. > (atexit): Force use of private atexit table via _dllonexit, > (_onexit): New function. Force use of private atexit table via > _dllonexit, > * mscvrt.def (atexit, _onexit): Add DATA keyword so that only > _imp_<_symbol> is visible in import lib. > * mscvrt20.def: Likewise. > * mscvrt40.def: Likewise. > * crtdll.def: Likewise. > > Index: crt1.c > =================================================================== > RCS file: /cvs/src/src/winsup/mingw/crt1.c,v > retrieving revision 1.1.1.1.40.2 > diff -u -p -r1.1.1.1.40.2 crt1.c > --- crt1.c 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.2 > +++ crt1.c 25 Apr 2002 04:42:18 -0000 > @@ -232,3 +233,20 @@ WinMainCRTStartup () > __mingw_CRTStartup (); > } > > +/* > + * We force use of library version of atexit, which is only > + * visible in import lib as _imp__atexit > + */ > +extern int (*_imp__atexit)(void (*)(void)); > +int atexit (void (* pfn )(void) ) > +{ > + return ( (*_imp__atexit)(pfn)); > +} > + > +/* Likewise for non-ANSI _onexit */ > +extern _onexit_t (*_imp___onexit)(_onexit_t); > +_onexit_t > +_onexit (_onexit_t pfn ) > +{ > + return (*_imp___onexit)(pfn); > +} > Index: crtdll.def > =================================================================== > RCS file: /cvs/src/src/winsup/mingw/crtdll.def,v > retrieving revision 1.1.1.1.40.1 > diff -u -p -r1.1.1.1.40.1 crtdll.def > --- crtdll.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 > +++ crtdll.def 25 Apr 2002 04:42:22 -0000 > @@ -414,7 +414,7 @@ _mkdir > _mktemp > _msize > _nextafter > -_onexit > +_onexit DATA > _open > _open_osfhandle > _osmajor_dll DATA > @@ -520,7 +520,7 @@ asctime > asin > atan > atan2 > -atexit > +atexit DATA > atof > atoi > atol > Index: dllcrt1.c > =================================================================== > RCS file: /cvs/src/src/winsup/mingw/dllcrt1.c,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 dllcrt1.c > --- dllcrt1.c 17 Feb 2000 19:38:31 -0000 1.1.1.1 > +++ dllcrt1.c 25 Apr 2002 04:42:22 -0000 > @@ -20,15 +20,16 @@ > * DISCLAMED. This includes but is not limited to warrenties of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > * > - * $Revision: 1.4 $ > - * $Author: cgf $ > - * $Date: 2000/02/05 04:04:42 $ > + * $Revision: 1.2 $ > + * $Author: earnie $ > + * $Date: 2001/06/05 00:26:30 $ > * > */ > - > +#include <stdlib.h> > #include <stdio.h> > #include <io.h> > #include <process.h> > +#include <errno.h> > #include <windows.h> > > /* Unlike normal crt1, I don't initialize the FPU, because the process > @@ -40,50 +41,156 @@ extern void __main (); > extern void __do_global_dtors (); > #endif > > +typedef void (* p_atexit_fn )(void); > +static p_atexit_fn* first_atexit; > +static p_atexit_fn* next_atexit; > + > +static void > +__dll_exit (void); > + > +/* This is based on the function in the Wine project's exit.c */ > +p_atexit_fn __dllonexit (p_atexit_fn, p_atexit_fn**, p_atexit_fn**); > + > + > extern BOOL WINAPI DllMain (HANDLE, DWORD, LPVOID); > > + > BOOL WINAPI > DllMainCRTStartup (HANDLE hDll, DWORD dwReason, LPVOID lpReserved) > { > BOOL bRet; > > if (dwReason == DLL_PROCESS_ATTACH) > { > + /* Initialize private atexit table for this dll. > + 32 is min size required by ANSI */ > + > + first_atexit = (p_atexit_fn*) malloc (32 * sizeof (p_atexit_fn)); > + if (first_atexit == NULL ) /* can't allocate memory */ > + { > + errno=ENOMEM; > + return FALSE; > + } > + *first_atexit = NULL; > + next_atexit = first_atexit; > + > +#ifdef DEBUG > + printf ("%s: DLL_PROCESS_ATTACH (%d)\n", __FUNCTION__); > +#endif > + > + > #ifdef __GNUC__ > - /* From libgcc.a, calls global class constructors. */ > + /* From libgcc.a, __main calls global class constructors, > + __do_global_ctors, which registers __do_global_dtors > + as the first entry of the private atexit table we > + have just initialised */ > __main (); > + > #endif > - } > + } > > /* > - * Call the user-supplied DllMain subroutine > + * Call the user-supplied DllMain subroutine. > + * This has to come after initialization of atexit table and > + * registration of global constructors. > * NOTE: DllMain is optional, so libmingw32.a includes a stub > * which will be used if the user does not supply one. > */ > + > bRet = DllMain (hDll, dwReason, lpReserved); > + /* Handle case where DllMain returns FALSE on attachment attempt. */ > > -#ifdef __GNUC__ > - if (dwReason == DLL_PROCESS_DETACH) > + if ((dwReason == DLL_PROCESS_ATTACH) && !bRet) > { > - /* From libgcc.a, calls global class destructors. */ > - __do_global_dtors (); > - } > +#ifdef DEBUG > + printf ("%s: DLL_PROCESS_ATTACH failed, cleaning up\n", __FUNCTION__); > #endif > > + __dll_exit (); /* Cleanup now. This will reset first_atexit to NULL > + so we know we've cleaned up */ > + } > + > + if (dwReason == DLL_PROCESS_DETACH) > + { > +#ifdef DEBUG > + printf ("%s: DLL_PROCESS_DETACH (%d)\n", __FUNCTION__); > +#endif > + /* If not attached, return FALSE. Cleanup already done above > + if failed attachment attempt. */ > + if (! first_atexit ) > + bRet = FALSE; > + else > + /* > + * We used to call __do_global_dtors () here. This is > + * no longer necessary since __do_global_dtors is now > + * registered at start (last out) of private atexit table. > + */ > + __dll_exit (); > + } > return bRet; > } > > +static > +void > +__dll_exit(void) > +/* Run LIFO terminators registered in private atexit table */ > +{ > + if ( first_atexit ) > + { > + p_atexit_fn* __last = next_atexit - 1; > + while ( __last >= first_atexit ) > + { > + if ( *__last != NULL ) > + { > +#ifdef DEBUG > + printf ("%s: Calling exit function 0x%x from 0x%x\n", > + __FUNCTION__, (unsigned)(*__last),(unsigned)__last); > +#endif > + (**__last) (); > + } > + __last--; > + } > + free ( first_atexit ) ; > + first_atexit = NULL ; > + } > + /* > + Make sure output buffers opened by DllMain or > + atexit-registered functions are flushed before detaching, > + otherwise we can have problems with redirected output. > + */ > + fflush (NULL); > +} > + > /* > - * For the moment a dummy atexit. Atexit causes problems in DLLs, especially > - * if they are dynamically loaded. For now atexit inside a DLL does nothing. > - * NOTE: We need this even if the DLL author never calls atexit because > - * the global constructor function __do_global_ctors called from __main > - * will attempt to register __do_global_dtors using atexit. > - * Thanks to Andrey A. Smirnov for pointing this one out. > + * The atexit exported from msvcrt.dll causes problems in DLLs. > + * Here, we override the exported version of atexit with one that passes the > + * private table initialised in DllMainCRTStartup to __dllonexit. > + * That means we have to hide the mscvrt.dll atexit because the > + * atexit defined here gets __dllonexit from the same lib. > */ > + > int > -atexit (void (*pfn) ()) > +atexit (p_atexit_fn pfn ) > { > - return 0; > +#ifdef DEBUG > + printf ("%s: registering exit function 0x%x at 0x%x\n", > + __FUNCTION__, (unsigned)pfn, (unsigned)next_atexit); > +#endif > + return (__dllonexit (pfn, &first_atexit, &next_atexit) > + == NULL ? -1 : 0 ); > } > > +/* > + * Likewise for non-ANSI function _onexit that may be called by > + * code in the dll. > + */ > + > +_onexit_t > +_onexit (_onexit_t pfn ) > +{ > +#ifdef DEBUG > + printf ("%s: registering exit function 0x%x at 0x%x\n", > + __FUNCTION__, (unsigned)pfn, (unsigned)next_atexit); > +#endif > + return ((_onexit_t) __dllonexit ((p_atexit_fn)pfn, &first_atexit, > &next_atexit)); > +} > Index: msvcrt.def > =================================================================== > RCS file: /cvs/src/src/winsup/mingw/msvcrt.def,v > retrieving revision 1.1.1.1.40.1 > diff -u -p -r1.1.1.1.40.1 msvcrt.def > --- msvcrt.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 > +++ msvcrt.def 25 Apr 2002 04:42:22 -0000 > @@ -365,7 +365,7 @@ _mkdir > _mktemp > _msize > _nextafter > -_onexit > +_onexit DATA > _open > _open_osfhandle > _osver DATA > @@ -546,7 +546,7 @@ asctime > asin > atan > atan2 > -atexit > +atexit DATA > atof > atoi > atol > Index: msvcrt20.def > =================================================================== > RCS file: /cvs/src/src/winsup/mingw/msvcrt20.def,v > retrieving revision 1.1.1.1.40.1 > diff -u -p -r1.1.1.1.40.1 msvcrt20.def > --- msvcrt20.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 > +++ msvcrt20.def 25 Apr 2002 04:42:22 -0000 > @@ -329,7 +329,7 @@ _msize > _mtlock > _mtunlock > _nextafter > -_onexit > +_onexit DATA > _open > _open_osfhandle > _osver > @@ -528,7 +528,7 @@ asctime > asin > atan > atan2 > -atexit > +atexit DATA > atof > atoi > atol > Index: msvcrt40.def > =================================================================== > RCS file: /cvs/src/src/winsup/mingw/msvcrt40.def,v > retrieving revision 1.1.1.1.40.1 > diff -u -p -r1.1.1.1.40.1 msvcrt40.def > --- msvcrt40.def 17 Apr 2002 02:34:22 -0000 1.1.1.1.40.1 > +++ msvcrt40.def 25 Apr 2002 04:42:25 -0000 > @@ -312,7 +312,7 @@ _msize > _mtlock > _mtunlock > _nextafter > -_onexit > +_onexit DATA > _open > _open_osfhandle > _osver > @@ -485,7 +485,7 @@ asctime > asin > atan > atan2 > -atexit > +atexit DATA > atof > atoi > atol > > http://messenger.yahoo.com.au - Yahoo! Messenger > - A great way to communicate long-distance for FREE! > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Paul G. <pga...@at...> - 2002-04-25 23:03:56
|
On 25 Apr 2002 at 19:35, Danny Smith wrote: > I am just about ready to roll GCC 3.1 into a beat release for mingw > next week but need advice on packaging details. Here is my tentative > plan. Please correct/augment/prune if deficient or excessive: > > 1) Core release: C, C++,Fortran, ObjC. Plus runtime libs. No shared > runtime libs (dlls) at this stage. 2) Extra: Gnat Ada compiler + libs > (the gcc.exe driver in core will recognize Ada as a supported language > but won't be able to do anything without this add-on). There are > known bugs in this relative to ACT's 3.14 release (based on gcc 2.8.1) > but AFAICT are limited to ACT's GTKAda, GLADE, and other ACT > "products". 3) Info files in binary dists above. HTML versions in > separate package. 4) source packaging follow 1,2. > > Most of my testing has been done using mingwex branch (and its > precursor in my sandpit) of runtime, but those extensions are not > necessary. Should I put libmingwex.a as system lib in specs? Should > I make IEEE extended reals (64 bit mantissa) as default like the rest > of the i386 world or stick with the MSVC way? Most definitely support IEEE extended reals as default. Been seeing a lot of new Win32 apps appearing which expect 64bit mantissas. I would include libmingwex.a as system lib in specs. Easier to track then, especially if linker questions come up. Paul G. > > These are the additions/patches to mingw not yet in official sources: > > 1) Mumit's tweaks for C+++ dllimport. > 2) Fastcall support (Eric Kohl and ReactOs friends, fiends and > allies). 3) --mms-bitfield-layout: The new-look replacement for > -fnative-struct. 4) C++ numeric_limits definitions for NaNs, > denorm_min etc. 5) Return of structs <= 64 bits in registers (eg > ldiv). > > If I get A into G some of these might make it by 3.3 ( I like odd > numbers). > > There are known deficiencies in C++ wrt wide char, locales. > I have avoided testing complex long double math in C++, so expect bugs > there as > > well. > > I think that's it. > > Any comment appreciated. Except one: Don't ask me for Java yet > > Danny > > http://messenger.yahoo.com.au - Yahoo! Messenger > - A great way to communicate long-distance for FREE! > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |