Re: [Harbour] g++2.95/g++3.3 bad build
On Wed, 16 Dec 2009, Tamas TEVESZ wrote: Hi, it seems that something is wrong with g++2.95 builds afterall. i took a fresh checkout of 13263, and tried building it on an older linux/i386 box that has gcc 2.95. (i changed HB_CMP to gcc-2.05 and g++-2.95 in config/linux/gcc.mk because this has no gcc and g++ links, but that's all that is.) both build fine, however the g++-2.95 build does exhibit the problem of hbrun not being able to start because: tres:~/tmp/h/harbour$ ./bin/linux/gcc/hbrun Unrecoverable error 9998: Harbour terminal (GT) initialization failure I've just confirmed your results using RH7.3 with GCC-2.96. c mode is fine. just run a quick test with gcc 3.3, same situation there too (same box, same everything); gcc 4.0 is ok in both modes, and on other boxes gcc 4.4 is ok too. so i guess this makes it g++ 4 builds broken. Yes, it's and it was exploited in last year. I was cleaning the code adding support for g++ about five years ago using xHarbour repository and above RH7.3 with gcc-2.96 and for sure it was working correctly. since now i am completely confused, would someone do a test build with g++ 2.95 (and perhaps gcc3 too) to doublecheck me? it'd be probably nice to know this both on linux and some other non-unixy platform too. Using C++ initialization (HB_STATIC_STARTUP) or recently added HB_INITSEG_STARTUP it works. The problem is only with __attribute__ ((constructor)) used in GCC-2.x C++ mode (I haven't tested GCC-3.x). I think that we exploited this problem in this year. It possible that it's also the reason of problems with SunPRO C builds in Linux, i.e. it GPFs in hbtest because not all constructors are executed and some symbol tables from .prg modules in HBRTL are not initialized. Anyhow it does not have to mean it's Harbour problem. It rather seems to be side effect of exploiting some limits in older GCC or GNU ld versions or maybe modified link command. I'll try to look at it closely but I do not promise that I'll give you the exact answer what is the reason of problem. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] g++2.95/g++3.3 bad build
On Wed, 16 Dec 2009, Przemysław Czerpak wrote: Hi, Yes, it's and it was exploited in last year. I was cleaning the code adding support for g++ about five years ago using xHarbour repository and above RH7.3 with gcc-2.96 and for sure it was working correctly. Update. I've just checked that RH7.3 was used only in chroot env and the real OS I used was newer so I GCC C++ builds were never tested with GCC 2.9x. Using C++ initialization (HB_STATIC_STARTUP) or recently added HB_INITSEG_STARTUP it works. The problem is only with __attribute__ ((constructor)) used in GCC-2.x C++ mode (I haven't tested GCC-3.x). I think that we exploited this problem in this year. It possible that it's also the reason of problems with SunPRO C builds in Linux, i.e. it GPFs in hbtest because not all constructors are executed and some symbol tables from .prg modules in HBRTL are not initialized. Anyhow it does not have to mean it's Harbour problem. It rather seems to be side effect of exploiting some limits in older GCC or GNU ld versions or maybe modified link command. I'll try to look at it closely but I do not promise that I'll give you the exact answer what is the reason of problem. The problem is trivial. GCC-2.96 when C++ mode is used ignores __attribute__ ((constructor)) and does not add functions with above attribute to .ctors segment. Looks like it was fixed in one of GCC-3.3x releases but I do not know the exact version. For sure it was fixed in the version I used adding g++. It will be good to check exact version to enable in hbinit.h HB_STATIC_STARTUP initialization for older GCC versions using C++ mode. Or maybe we should enable it by default for _ALL_ (also MSVC) compilers using C++ mode? Unlike all other startup initialization methods this one uses only standard C++ functionality without any compiler specific tricks so it's fully portable code in C++ world. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] g++2.95/g++3.3 bad build
On Wed, 16 Dec 2009, Przemysław Czerpak wrote:
hi,
The problem is trivial. GCC-2.96 when C++ mode is used ignores
__attribute__ ((constructor)) and does not add functions with
above attribute to .ctors segment. Looks like it was fixed in
one of GCC-3.3x releases but I do not know the exact version.
i think 3.3.6 was the last of the 3.3s, but anyway.
i have a hunch that i am verifying now (only 3.3 g++ is done so far,
this is a slow machine, but so far the only result i have is
promising): change the order of initializers.
this makes g++ fall into the static category (because of __cplusplus),
not into using fun attributes (because of __GNUC__); moreover this
makes all c++ compilers fall into this, which i gather is preferred,
if one is capable of doing c++-style initializers.
this has so far fixed g++-3.3, but i'm still running tests and
re-tests and re-tests.
Index: include/hbinit.h
===
--- include/hbinit.h(revision 13266)
+++ include/hbinit.h(working copy)
@@ -112,6 +112,33 @@
#define HB_CALL_ON_STARTUP_END( func ) \
}
+#elif defined( HB_STATIC_STARTUP ) || defined( __cplusplus )
+
+ #if defined( HB_PRAGMA_STARTUP ) || defined( HB_DATASEG_STARTUP )
+ #error Wrong macros set for startup code - clean your make/env settings.
+ #endif
+
+ #define HB_INIT_SYMBOLS_BEGIN( func ) \
+ static HB_SYMB symbols_table[] = {
+
+ #define HB_INIT_SYMBOLS_EX_END( func, module, id, vpcode ) \
+ }; \
+ static PHB_SYMB symbols = hb_vmProcessSymbols( symbols_table, (USHORT) (
sizeof( symbols_table ) / sizeof( HB_SYMB ) ), (module), (id), (vpcode) ); \
+
+ #define HB_CALL_ON_STARTUP_BEGIN( func ) \
+ static int func( void ) \
+ {
+
+ /* this allows any macros to be preprocessed first
+ so that token pasting is handled correctly */
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ _HB_CALL_ON_STARTUP_END( func )
+
+ #define _HB_CALL_ON_STARTUP_END( func ) \
+ return 0; \
+ } \
+ static int static_int_##func = func();
+
#elif defined( HB_INITSEG_STARTUP )
#if defined( HB_PRAGMA_STARTUP ) || defined( HB_DATASEG_STARTUP )
@@ -216,33 +243,6 @@
* See the C output of a generated prg for example
*/
-#elif defined( HB_STATIC_STARTUP ) || defined( __cplusplus )
-
- #if defined( HB_PRAGMA_STARTUP ) || defined( HB_DATASEG_STARTUP )
- #error Wrong macros set for startup code - clean your make/env settings.
- #endif
-
- #define HB_INIT_SYMBOLS_BEGIN( func ) \
- static HB_SYMB symbols_table[] = {
-
- #define HB_INIT_SYMBOLS_EX_END( func, module, id, vpcode ) \
- }; \
- static PHB_SYMB symbols = hb_vmProcessSymbols( symbols_table, (USHORT) (
sizeof( symbols_table ) / sizeof( HB_SYMB ) ), (module), (id), (vpcode) ); \
-
- #define HB_CALL_ON_STARTUP_BEGIN( func ) \
- static int func( void ) \
- {
-
- /* this allows any macros to be preprocessed first
- so that token pasting is handled correctly */
- #define HB_CALL_ON_STARTUP_END( func ) \
- _HB_CALL_ON_STARTUP_END( func )
-
- #define _HB_CALL_ON_STARTUP_END( func ) \
- return 0; \
- } \
- static int static_int_##func = func();
-
#elif defined( HB_PRAGMA_STARTUP ) || \
defined( __BORLANDC__ ) || defined( __LCC__ ) || defined( __POCC__ ) ||
defined( __XCC__ )
It will be good to check exact version to enable in hbinit.h
HB_STATIC_STARTUP initialization for older GCC versions using
C++ mode. Or maybe we should enable it by default for _ALL_
(also MSVC) compilers using C++ mode? Unlike all other startup
initialization methods this one uses only standard C++ functionality
without any compiler specific tricks so it's fully portable code
in C++ world.
i think i am in favor of this.
--
[-]
mkdir /nonexistentIndex: include/hbinit.h
===
--- include/hbinit.h (revision 13266)
+++ include/hbinit.h (working copy)
@@ -112,6 +112,33 @@
#define HB_CALL_ON_STARTUP_END( func ) \
}
+#elif defined( HB_STATIC_STARTUP ) || defined( __cplusplus )
+
+ #if defined( HB_PRAGMA_STARTUP ) || defined( HB_DATASEG_STARTUP )
+ #error Wrong macros set for startup code - clean your make/env settings.
+ #endif
+
+ #define HB_INIT_SYMBOLS_BEGIN( func ) \
+ static HB_SYMB symbols_table[] = {
+
+ #define HB_INIT_SYMBOLS_EX_END( func, module, id, vpcode ) \
+ }; \
+ static PHB_SYMB symbols = hb_vmProcessSymbols( symbols_table, (USHORT) ( sizeof( symbols_table ) / sizeof( HB_SYMB ) ), (module), (id), (vpcode) ); \
+
+ #define HB_CALL_ON_STARTUP_BEGIN( func ) \
+ static int func( void ) \
+ {
+
+ /* this allows any macros to be preprocessed first
+ so that token pasting is handled correctly */
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ _HB_CALL_ON_STARTUP_END( func )
+
+ #define
Re: [Harbour] g++2.95/g++3.3 bad build
On Wed, 16 Dec 2009, Tamas TEVESZ wrote: hi, i have a hunch that i am verifying now (only 3.3 g++ is done so far, this is a slow machine, but so far the only result i have is promising): change the order of initializers. fyi that fixed g++ 2.95 as well as 3.3.6, without any noticeable ill effect to others. It will be good to check exact version to enable in hbinit.h HB_STATIC_STARTUP initialization for older GCC versions using C++ mode. Or maybe we should enable it by default for _ALL_ (also MSVC) compilers using C++ mode? Unlike all other startup initialization methods this one uses only standard C++ functionality without any compiler specific tricks so it's fully portable code in C++ world. i think i am in favor of this. even more so :) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
