From: Ranjit M. <rm...@vs...> - 2002-12-17 19:02:07
|
Hi, I'm getting persistent bootstrap errors while cross-compiling GCC 3.3 snapshot dated 2002-12-16 with Danny's recent patches applied to it: the build of libstdc++-v3 fails with "Undefined macro __GTHREAD_MUTEX_INIT". The gcc "gthr.h" header says that a gthread implementation must define this macro, but "gthr-win32.h" does not. This macro seems to be used by "atomicity.h" in "config/cpu/generic" for libstdc++-v3, which is being used instead of "config/cpu/i486" - why? This problem has cropped up only recently, as older snapshots used to build fine for me. Does anyone have any idea on this? Thanks for your help in advance. Sincerely Yours, Ranjit. -- Ranjit Mathew Email: rmathew AT hotmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/ |
From: Danny S. <dan...@cl...> - 2002-12-17 23:50:40
|
----- Original Message ----- From: "Ranjit Mathew" <rm...@vs...> To: "MinGW Developers" <min...@li...> Sent: Tuesday, 17 December 2002 19:03 Subject: [MinGW-dvlpr] GCC 3.3 Bootstrap Failure: Undefined __GTHREAD_MUTEX_INIT > Hi, > > I'm getting persistent bootstrap errors while > cross-compiling GCC 3.3 snapshot dated 2002-12-16 > with Danny's recent patches applied to it: > the build of libstdc++-v3 fails with "Undefined > macro __GTHREAD_MUTEX_INIT". > > The gcc "gthr.h" header says that a gthread implementation > must define this macro, but "gthr-win32.h" does not. > Read again. __GTHREAD_MUTEX_INIT to initialize __gthread_mutex_t to get a fast non-recursive mutex. __GTHREAD_MUTEX_INIT_FUNCTION some systems can't initialize a mutex without a function call. On such systems, define this to a function which looks like this: void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *) Don't define __GTHREAD_MUTEX_INIT in this case mingw uses __GTHREAD_MUTEX_INIT_FUNCTION. This caused problems when this patch was added: 2002-11-07 Phil Edwards <pm...@gc...> Richard Earnshaw <rea...@ar...> * config/cpu/generic/atomicity.h: Provide atomic __exchange_and_add and __atomic_add. > This macro seems to be used by "atomicity.h" in > "config/cpu/generic" for libstdc++-v3, which is being > used instead of "config/cpu/i486" - why? > > This problem has cropped up only recently, as older > snapshots used to build fine for me. > > Does anyone have any idea on this? Yup. force use of i486/atomicity.h in libstdc++/configure.target mingw32*) os_include_dir="os/mingw32" ATOMICITYH="cpu/i486" # cmodel=c # c_compatibility=yes ;; I must have removed the ATOMICITYH along with the cmodel/c_compatability lines(which I use for testing the cheaders=c model) when I did the diff that I posted to group. Danny > > Thanks for your help in advance. > > Sincerely Yours, > Ranjit. > > -- > Ranjit Mathew Email: rmathew AT hotmail DOT com > Bangalore, > INDIA. Web: http://ranjitmathew.tripod.com/ > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Ranjit M. <rm...@ho...> - 2002-12-18 07:37:49
|
Danny Smith wrote: >> This macro seems to be used by "atomicity.h" in >> "config/cpu/generic" for libstdc++-v3, which is being >> used instead of "config/cpu/i486" - why? >> >> This problem has cropped up only recently, as older >> snapshots used to build fine for me. >> >> Does anyone have any idea on this? > > Yup. force use of i486/atomicity.h in libstdc++/configure.target > > mingw32*) > os_include_dir="os/mingw32" > ATOMICITYH="cpu/i486" > # cmodel=c > # c_compatibility=yes > ;; > > I must have removed the ATOMICITYH along with the cmodel/c_compatability > lines(which I use for testing the cheaders=c model) when I did the diff > that I posted to group. Much thanks for that! I'll try it out once more. However, IMHO, you should set cpu_include_dir="cpu/i486" to be more correct - right now, it only has atomicity.h, but it might get other cpu-specific headers later. The problem also wouldn't have come if the folder were "i386" instead of "i486", as this is the value of target_cpu for target alias "mingw32". I'm sorry for not having RTF-configure.target-script - it's all given very plainly at the top of the script. :-( AFAICT, you should also have the same for the cygwin target. The fact that these are not there for either mingw32 or cygwin means that it is a "bug" (in a way) - Danny, have you submitted a patch to the libstdc++-v3 developers for this? Sincerely Yours, Ranjit. -- Ranjit Mathew Email: rmathew AT hotmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/ |
From: Danny S. <dan...@cl...> - 2002-12-18 09:58:18
|
----- Original Message ----- From: "Ranjit Mathew" <rm...@ho...> To: "MinGW Developers" <min...@li...> Sent: Wednesday, 18 December 2002 07:37 Subject: [MinGW-dvlpr] Re: GCC 3.3 Bootstrap Failure: Undefined __GTHREAD_MUTEX_INIT > Danny Smith wrote: > >> This macro seems to be used by "atomicity.h" in > >> "config/cpu/generic" for libstdc++-v3, which is being > >> used instead of "config/cpu/i486" - why? > >> > >> This problem has cropped up only recently, as older > >> snapshots used to build fine for me. > >> > >> Does anyone have any idea on this? > > > > Yup. force use of i486/atomicity.h in libstdc++/configure.target > > > > mingw32*) > > os_include_dir="os/mingw32" > > ATOMICITYH="cpu/i486" > > # cmodel=c > > # c_compatibility=yes > > ;; > > > > I must have removed the ATOMICITYH along with the cmodel/c_compatability > > lines(which I use for testing the cheaders=c model) when I did the diff > > that I posted to group. > > Much thanks for that! I'll try it out once more. > > However, IMHO, you should set cpu_include_dir="cpu/i486" to > be more correct - right now, it only has atomicity.h, but it > might get other cpu-specific headers later. Maybe. It used to have a very incomplete cpu_limits.h but that is all builtin now. > > The problem also wouldn't have come if the folder were > "i386" instead of "i486", as this is the value of target_cpu > for target alias "mingw32". > Yes, The old contents of i386 dir were the same as current i486 (and used asm instructions that only worked on i486 and higher - that was the bug that finally got caught after many years and motivated the generic atomicity.h). > I'm sorry for not having RTF-configure.target-script - it's > all given very plainly at the top of the script. :-( > > AFAICT, you should also have the same for the cygwin target. > The fact that these are not there for either mingw32 or cygwin > means that it is a "bug" (in a way) - Danny, have you > submitted a patch to the libstdc++-v3 developers for this? > For cygwin, the generic version works fine since it does have _GTHREAD_MUTEX_INIT. However, its moot point since official cygwin releases configure as i686 and I doubt if anyone explicitly configure cygwin as i386. Currently the cpu default for mingw is i586, but I think it should be i686 since the latter gets better testing on Linux targets No I haven't submitted patch. Its sitting under a pile that will wait till next year. Danny > Sincerely Yours, > Ranjit. > > -- > Ranjit Mathew Email: rmathew AT hotmail DOT com > > Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/ > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Ranjit M. <rm...@vs...> - 2002-12-18 19:51:18
|
Danny Smith wrote: >>>Yup. force use of i486/atomicity.h in libstdc++/configure.target >>> >>> mingw32*) >>> os_include_dir="os/mingw32" >>> ATOMICITYH="cpu/i486" >>># cmodel=c >>># c_compatibility=yes >>> ;; With this change, I'm finally able to build GCC 3.3 C/C++ properly. Thank you once again. > Currently the cpu default for mingw is i586, but I think it should be > i686 since the latter gets better testing on Linux targets > > No I haven't submitted patch. Its sitting under a pile that will wait > till next year. If you want, I'll submit it. It's pretty trivial anyways. Would you prefer the "cpu_include_dir=" form or the "ATOMICITYH=" form? Sincerely Yours, Ranjit. -- Ranjit Mathew Email: rmathew AT hotmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/ |
From: Ranjit M. <rm...@vs...> - 2002-12-18 19:55:55
|
Danny Smith wrote: >>>Yup. force use of i486/atomicity.h in libstdc++/configure.target >>> >>> mingw32*) >>> os_include_dir="os/mingw32" >>> ATOMICITYH="cpu/i486" >>># cmodel=c >>># c_compatibility=yes >>> ;; With this change, I'm finally able to build GCC 3.3 C/C++ properly. Thank you once again. > Currently the cpu default for mingw is i586, but I think it should be > i686 since the latter gets better testing on Linux targets > > No I haven't submitted patch. Its sitting under a pile that will wait > till next year. If you want, I'll submit it. It's pretty trivial anyways. Would you prefer the "cpu_include_dir=" form or the "ATOMICITYH=" form? Sincerely Yours, Ranjit. -- Ranjit Mathew Email: rmathew AT hotmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/ |
From: Danny S. <dan...@cl...> - 2002-12-18 20:37:17
|
> Danny Smith wrote: > >>>Yup. force use of i486/atomicity.h in libstdc++/configure.target > >>> > >>> mingw32*) > >>> os_include_dir="os/mingw32" > >>> ATOMICITYH="cpu/i486" > > If you want, I'll submit it. It's pretty trivial anyways. Would you > prefer the "cpu_include_dir=" form or the "ATOMICITYH=" form? Thanks for the offer. I would be grateful. It doesn't really matter to me which you submit. It fixes atomicity.h, so that's what I would use. I haven't tested setting cpu_include_dir. Danny > > Sincerely Yours, > Ranjit. > > -- > Ranjit Mathew Email: rmathew AT hotmail DOT com > Bangalore, > INDIA. Web: http://ranjitmathew.tripod.com/ > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Ranjit M. <rm...@ho...> - 2002-12-19 12:22:45
|
Danny Smith wrote: > Thanks for the offer. I would be grateful. > It doesn't really matter to me which you submit. It fixes atomicity.h, > so that's what I would use. I haven't tested setting cpu_include_dir. No problem! See the following message for what I've submitted to the libstdc++ developers: http://article.gmane.org/gmane.comp.gcc.libstdc%2B%2B.devel/2967 Ranjit. -- Ranjit Mathew Email: rmathew AT hotmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/ |
From: <ch...@it...> - 2002-12-21 20:25:40
|
Fastcall support is now in Binutils and GCC CVS. Many thanks to all involved in making this happen. Vanilla Binutils and GCC can now be used to build ReactOS. Casper Hornstrup |