[Harbour] sunpro/linux build failure
hi, przemek, i'm having a build failure with sunpro/linux. i've went quite outside my comfort zone by installing centos 5.5 (centos 5 is explicitly supported by studio 12u1) i386 (just in case, the no surprises fallback). c mode builds but doesn't work (we've been there already), but now cpp mode doesn't even build. ! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org ! MAKE: make 3.81 /bin/sh ! HB_BUILD_MODE: cpp ! HB_HOST_PLAT: linux (x86) HB_SHELL: sh ! HB_PLATFORM: linux (x86) (autodetected) ! HB_COMPILER: sunpro (autodetected: /opt/sunstudio12.1/bin/) ! HB_HOST_PKGM: rpm ! Component: 'zlib' found in /usr/include ! Component: 'pcre' found in /usr/include ! Component: 'openssl' found in /usr/include ! Component: 'gpm' found in /usr/include ! Component: 'slang' found in /usr/include/slang ! Component: 'curses' found in /usr/include ! Component: 'x11' found in /usr/include ! Component: 'wattcp/watt-32' not supported on linux platform ! HB_INSTALL_PREFIX automatically set to: /usr/local [...] sunCC -I. -I../../../../../include -fast -xnolibmopt -erroff=%none -DHB_LEGACY_TYPES_OFF -DHB_HAS_PCRE -I/usr/include -DHB_HAS_ZLIB -I/usr/include -o filebuf.o -c ../../../filebuf.c ../../../filebuf.c, line 342: Error: Cannot cast from __u_quad_t to unsigned long. ../../../filebuf.c, line 386: Error: Cannot cast from __u_quad_t to unsigned long. this is referring to statbuf.st_dev, which indeed is ull, but sunpro doesn't override this anywhere, so it's ull with other compilers too, where it works fine. could you take a quick look at it sometime? thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] protect non-standard baudrates in tpathy/tpunix
plus add some, those that are also in src/rtl/hbcom.c Index: contrib/hbtpathy/tpunix.c === --- contrib/hbtpathy/tpunix.c (revision 14656) +++ contrib/hbtpathy/tpunix.c (working copy) @@ -114,9 +114,27 @@ case 9600:baud = B9600;break; case 19200: baud = B19200; break; case 38400: baud = B38400; break; +#if defined( B57600 ) case 57600: baud = B57600; break; +#endif +#if defined( B115200 ) case 115200: baud = B115200; break; +#endif +#if defined( B230400 ) case 230400: baud = B230400; break; +#endif +#ifdef B460800 + case 460800: baud = B460800; break; +#endif +#ifdef B50 + case 50: baud = B50; break; +#endif +#ifdef B576000 + case 576000: baud = B576000; break; +#endif +#ifdef B921600 + case 921600: baud = B921600; break; +#endif } cfsetispeed( options, baud ); -- [-] mkdir /nonexistentIndex: contrib/hbtpathy/tpunix.c === --- contrib/hbtpathy/tpunix.c (revision 14656) +++ contrib/hbtpathy/tpunix.c (working copy) @@ -114,9 +114,27 @@ case 9600:baud = B9600;break; case 19200: baud = B19200; break; case 38400: baud = B38400; break; +#if defined( B57600 ) case 57600: baud = B57600; break; +#endif +#if defined( B115200 ) case 115200: baud = B115200; break; +#endif +#if defined( B230400 ) case 230400: baud = B230400; break; +#endif +#ifdef B460800 + case 460800: baud = B460800; break; +#endif +#ifdef B50 + case 50: baud = B50; break; +#endif +#ifdef B576000 + case 576000: baud = B576000; break; +#endif +#ifdef B921600 + case 921600: baud = B921600; break; +#endif } cfsetispeed( options, baud ); ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] improve clang a bit
maybe it could be turned around a bit so that all the llvm/clang things are moved out of the gnuc block, but at the same time it fits the way mingw/rsx*/etc are handled now. i'd say leave it like this, and maybe do some shuffling several clang and/or llvm versions in the future, when things come to light. right now the question basiclaly is: can you get clang without llvm? can you get llvm without clang? i don't really know the answer to these, and that's what's needed to decide whether or not (and how) to move it out into it's own block. actually, i've been thinking, and, embarrasingly enough, you are right again. the current way is very wrong. when compiled with clang1, hb_compiler() will return LLVM/Clang C 4.2.1. this means that this harbour was compiled with clang version 4.2.1, whereas in reality this harbour was compiled with clang version 1.1, which has no viable means of telling it's version information, but it pretends to be gcc 4.2.1. if and when there will be a clang version 4.2.1, there will be no way of telling what's going on. to that end, i propose the following: - clang can be picked based on the presence of __clang__ - clang v2+ can be picked based on the presence of __clang_major__ - this is enough to pick out clang v1.x, which is about as precise as we can get identifying clang 1.x (and this is rather enough). the c++ fragment here is rather superfluous since there's no c++ in clang1, trim as you see fit) - with __llvm__ and __GNUC__ we are in llvm-gcc-land (for which we have no support, trim as you see fit) - you don't get __llvm__ only by itself (it'll have to be accompanied by a frontend) (and since everything in sunpro is hex, turn the bcd decoder to hex as well) Index: src/common/hbver.c === --- src/common/hbver.c (revision 14644) +++ src/common/hbver.c (working copy) @@ -700,7 +700,7 @@ iVerPatch = 0; #endif -#elif defined( __llvm__ ) defined( __clang_major__ ) +#elif defined( __clang__ ) defined( __clang_major__ ) pszName = LLVM/Clang C; @@ -712,6 +712,33 @@ hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); #endif +#elif defined( __clang__ ) + + pszName = LLVM/Clang C; + iVerMajor = iVerMinor = iVerPatch = 0; + + #if defined( __cplusplus ) + hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); + #endif + + hb_strncat( szSub, 1.x, sizeof( szSub ) - 1 ); + +#elif defined( __llvm__ ) defined( __GNUC__ ) + + pszName = LLVM/GNU C + + #if defined( __cplusplus ) + hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); + #endif + + iVerMajor = __GNUC__; + iVerMinor = __GNUC_MINOR__; + #if defined( __GNUC_PATCHLEVEL__ ) + iVerPatch = __GNUC_PATCHLEVEL__; + #else + iVerPatch = 0; + #endif + #elif defined( __GNUC__ ) #if defined( __DJGPP__ ) @@ -726,12 +753,6 @@ pszName = EMX/RSXNT/Win32 GNU C; #elif defined( __EMX__ ) pszName = EMX GNU C; - #elif defined( __clang__ ) defined( __llvm__ ) - pszName = LLVM/Clang C; - #elif defined( __clang__ ) - pszName = Clang/GNU C; - #elif defined( __llvm__ ) - pszName = LLVM/GNU C; #else pszName = GNU C; #endif @@ -758,7 +779,7 @@ #else iVerMajor = __SUNPRO_C / 0x1000; iVerMinor = __SUNPRO_C / 0x10 0xff; - iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16; + iVerMinor = iVerMinor / 0x10 * 0xa + iVerMinor % 0x10; iVerPatch = __SUNPRO_C 0xf; #endif @@ -772,7 +793,7 @@ #else iVerMajor = __SUNPRO_CC / 0x1000; iVerMinor = __SUNPRO_CC / 0x10 0xff; - iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16; + iVerMinor = iVerMinor / 0x10 * 0xa + iVerMinor % 0x10; iVerPatch = __SUNPRO_CC 0xf; #endif -- [-] mkdir /nonexistentIndex: src/common/hbver.c === --- src/common/hbver.c (revision 14644) +++ src/common/hbver.c (working copy) @@ -700,7 +700,7 @@ iVerPatch = 0; #endif -#elif defined( __llvm__ ) defined( __clang_major__ ) +#elif defined( __clang__ ) defined( __clang_major__ ) pszName = LLVM/Clang C; @@ -712,6 +712,33 @@ hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); #endif +#elif defined( __clang__ ) + + pszName = LLVM/Clang C; + iVerMajor = iVerMinor = iVerPatch = 0; + + #if defined( __cplusplus ) + hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); + #endif + + hb_strncat( szSub, 1.x, sizeof( szSub ) - 1 ); + +#elif defined( __llvm__ ) defined( __GNUC__ ) + + pszName = LLVM/GNU C + + #if defined( __cplusplus ) + hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); + #endif + + iVerMajor = __GNUC__; + iVerMinor = __GNUC_MINOR__; + #if defined( __GNUC_PATCHLEVEL__ ) + iVerPatch = __GNUC_PATCHLEVEL__; + #else + iVerPatch = 0; + #endif + #elif defined( __GNUC__ ) #if defined( __DJGPP__ ) @@ -726,12
[Harbour] improve clang a bit
- clang 2 does c++ now, so only fall back to c mode if we are running clang1 - clang2 has some nice macros for version stuff, use them tested with both clang2 (bsd) and clang1 (linux), both appear to be fine. thanks to viktor for solving my troubles with the $($(shell(($($((subst))$)zoink))$)$))kaboom)$)) madness. Index: src/common/hbver.c === --- src/common/hbver.c (revision 14637) +++ src/common/hbver.c (working copy) @@ -700,6 +700,18 @@ iVerPatch = 0; #endif +#elif defined( __llvm__ ) defined( __clang_major__ ) + + pszName = LLVM/Clang C; + + iVerMajor = __clang_major__; + iVerMinor = __clang_minor__; + iVerPatch = __clang_patchlevel__; + + #if defined( __cplusplus ) + hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); + #endif + #elif defined( __GNUC__ ) #if defined( __DJGPP__ ) @@ -783,6 +795,15 @@ else hb_strncpy( pszCompiler, (unknown), COMPILER_BUF_SIZE - 1 ); +#if defined( __clang_version__ ) + if (strstr( __clang_version__, ()) + /* 2.0 (trunk 103176) - (trunk 103176) */ + hb_snprintf( szSub, sizeof( szSub ), %s, strstr( __clang_version__, ()); + else + hb_snprintf( szSub, sizeof( szSub ), (%s), __clang_version__); + hb_strncat( pszCompiler, szSub, COMPILER_BUF_SIZE - 1 ); +#endif + #if defined( __DJGPP__ ) hb_snprintf( szSub, sizeof( szSub ), (DJGPP %i.%02i), ( int ) __DJGPP__, ( int ) __DJGPP_MINOR__ ); hb_strncat( pszCompiler, szSub, COMPILER_BUF_SIZE - 1 ); Index: config/bsd/clang.mk === --- config/bsd/clang.mk (revision 14637) +++ config/bsd/clang.mk (working copy) @@ -3,8 +3,11 @@ # ifeq ($(HB_BUILD_MODE),cpp) - # -ccc-clang-cxx - HB_CMP := clang + ifneq ($(findstring clang$(subst x, ,x)version$(subst x, ,x)1,$(shell clang --version)),) + HB_BUILD_MODE := c + else + HB_CMP := clang++ + endif else HB_CMP := clang endif Index: config/linux/clang.mk === --- config/linux/clang.mk (revision 14637) +++ config/linux/clang.mk (working copy) @@ -3,8 +3,11 @@ # ifeq ($(HB_BUILD_MODE),cpp) - # -ccc-clang-cxx - HB_CMP := clang + ifneq ($(findstring clang$(subst x, ,x)version$(subst x, ,x)1,$(shell clang --version)),) + HB_BUILD_MODE := c + else + HB_CMP := clang++ + endif else HB_CMP := clang endif -- [-] mkdir /nonexistentIndex: src/common/hbver.c === --- src/common/hbver.c (revision 14637) +++ src/common/hbver.c (working copy) @@ -700,6 +700,18 @@ iVerPatch = 0; #endif +#elif defined( __llvm__ ) defined( __clang_major__ ) + + pszName = LLVM/Clang C; + + iVerMajor = __clang_major__; + iVerMinor = __clang_minor__; + iVerPatch = __clang_patchlevel__; + + #if defined( __cplusplus ) + hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); + #endif + #elif defined( __GNUC__ ) #if defined( __DJGPP__ ) @@ -783,6 +795,15 @@ else hb_strncpy( pszCompiler, (unknown), COMPILER_BUF_SIZE - 1 ); +#if defined( __clang_version__ ) + if (strstr( __clang_version__, ()) + /* 2.0 (trunk 103176) - (trunk 103176) */ + hb_snprintf( szSub, sizeof( szSub ), %s, strstr( __clang_version__, ()); + else + hb_snprintf( szSub, sizeof( szSub ), (%s), __clang_version__); + hb_strncat( pszCompiler, szSub, COMPILER_BUF_SIZE - 1 ); +#endif + #if defined( __DJGPP__ ) hb_snprintf( szSub, sizeof( szSub ), (DJGPP %i.%02i), ( int ) __DJGPP__, ( int ) __DJGPP_MINOR__ ); hb_strncat( pszCompiler, szSub, COMPILER_BUF_SIZE - 1 ); Index: config/bsd/clang.mk === --- config/bsd/clang.mk (revision 14637) +++ config/bsd/clang.mk (working copy) @@ -3,8 +3,11 @@ # ifeq ($(HB_BUILD_MODE),cpp) - # -ccc-clang-cxx - HB_CMP := clang + ifneq ($(findstring clang$(subst x, ,x)version$(subst x, ,x)1,$(shell clang --version)),) + HB_BUILD_MODE := c + else + HB_CMP := clang++ + endif else HB_CMP := clang endif Index: config/linux/clang.mk === --- config/linux/clang.mk (revision 14637) +++ config/linux/clang.mk (working copy) @@ -3,8 +3,11 @@ # ifeq ($(HB_BUILD_MODE),cpp) - # -ccc-clang-cxx - HB_CMP := clang + ifneq ($(findstring clang$(subst x, ,x)version$(subst x, ,x)1,$(shell clang --version)),) + HB_BUILD_MODE := c + else + HB_CMP := clang++ + endif else HB_CMP := clang endif ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] improve clang a bit
On Sun, 30 May 2010, Viktor Szakáts wrote: hi, Thanks for the patch. We already had LLVM/Clang C detection inside the __GNUC__ branch, is it still necessary, or can we now safely delete it? the current one is for clang1 (no clang_major and friends, but defines gnuc and llvm), while the new snippet is for clang2 (which has clang_major and friends -- it still defines gnuc and the shebang, but i don't think i belongs in that branch. maybe it could be turned around a bit so that all the llvm/clang things are moved out of the gnuc block, but at the same time it fits the way mingw/rsx*/etc are handled now. i'd say leave it like this, and maybe do some shuffling several clang and/or llvm versions in the future, when things come to light. right now the question basiclaly is: can you get clang without llvm? can you get llvm without clang? i don't really know the answer to these, and that's what's needed to decide whether or not (and how) to move it out into it's own block. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14641] trunk/harbour
On Sun, 30 May 2010, vszak...@users.sourceforge.net wrote: + Clearing forced C++ mode if clang 1.x is detected. (Patch from Tamas Tevesz. Slight fix added by me to set HB_CMP when falling back to C mode. I didn't make tests though.) ; NOTE: Probably HB_BUILD_MODE=c should be export-ed to avoid double evaluation. Pls test it. it appears to be working as i think it should. (just noticed, shouldn't the darwin clang spec updated, too? or will this xcode-thing work this out differently?) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] fix sunpro ident
i think this takes care of sunpros =0x5100 (studio 12). have no earlier ones readily installed, but they should stay ok. Index: src/common/hbver.c === --- src/common/hbver.c (revision 14628) +++ src/common/hbver.c (working copy) @@ -739,30 +739,29 @@ #elif defined( __SUNPRO_C ) pszName = Sun C; - #if __SUNPRO_C 0x600 + #if __SUNPRO_C 0x1000 iVerMajor = __SUNPRO_C / 0x100; iVerMinor = ( __SUNPRO_C 0xff ) / 0x10; iVerPatch = __SUNPRO_C 0xf; #else - /* Until someone at Sun somes up with a reliable way of identifying - Sun Studio releases = about 11. */ - iVerMajor = iVerMinor = iVerPatch = 0; - hb_snprintf( szSub, sizeof( szSub ) - 1, (ident 0x%X), __SUNPRO_C ); + iVerMajor = __SUNPRO_C / 0x1000; + iVerMinor = __SUNPRO_C / 0x10 0xff; + iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16; + iVerPatch = __SUNPRO_C 0xf; #endif #elif defined( __SUNPRO_CC ) pszName = Sun C++; - #if __SUNPRO_CC 0x600 - pszName = Sun C++; + #if __SUNPRO_CC 0x1000 iVerMajor = __SUNPRO_CC / 0x100; iVerMinor = ( __SUNPRO_CC 0xff ) / 0x10; iVerPatch = __SUNPRO_CC 0xf; #else - /* Until someone at Sun somes up with a reliable way of identifying - Sun Studio releases = about 11. */ - iVerMajor = iVerMinor = iVerPatch = 0; - hb_snprintf( szSub, sizeof( szSub ) - 1, (ident 0x%X), __SUNPRO_CC ); + iVerMajor = __SUNPRO_CC / 0x1000; + iVerMinor = __SUNPRO_CC / 0x10 0xff; + iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16; + iVerPatch = __SUNPRO_CC 0xf; #endif #else -- [-] mkdir /nonexistentIndex: src/common/hbver.c === --- src/common/hbver.c (revision 14628) +++ src/common/hbver.c (working copy) @@ -739,30 +739,29 @@ #elif defined( __SUNPRO_C ) pszName = Sun C; - #if __SUNPRO_C 0x600 + #if __SUNPRO_C 0x1000 iVerMajor = __SUNPRO_C / 0x100; iVerMinor = ( __SUNPRO_C 0xff ) / 0x10; iVerPatch = __SUNPRO_C 0xf; #else - /* Until someone at Sun somes up with a reliable way of identifying - Sun Studio releases = about 11. */ - iVerMajor = iVerMinor = iVerPatch = 0; - hb_snprintf( szSub, sizeof( szSub ) - 1, (ident 0x%X), __SUNPRO_C ); + iVerMajor = __SUNPRO_C / 0x1000; + iVerMinor = __SUNPRO_C / 0x10 0xff; + iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16; + iVerPatch = __SUNPRO_C 0xf; #endif #elif defined( __SUNPRO_CC ) pszName = Sun C++; - #if __SUNPRO_CC 0x600 - pszName = Sun C++; + #if __SUNPRO_CC 0x1000 iVerMajor = __SUNPRO_CC / 0x100; iVerMinor = ( __SUNPRO_CC 0xff ) / 0x10; iVerPatch = __SUNPRO_CC 0xf; #else - /* Until someone at Sun somes up with a reliable way of identifying - Sun Studio releases = about 11. */ - iVerMajor = iVerMinor = iVerPatch = 0; - hb_snprintf( szSub, sizeof( szSub ) - 1, (ident 0x%X), __SUNPRO_CC ); + iVerMajor = __SUNPRO_CC / 0x1000; + iVerMinor = __SUNPRO_CC / 0x10 0xff; + iVerMinor = iVerMinor / 16 * 10 + iVerMinor % 16; + iVerPatch = __SUNPRO_CC 0xf; #endif #else ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] add dragonfly support
hi, the following adds dragonfly support to the bsd support chunk. some notes: --- config/bsd/libs.mk (revision 14580) +++ config/bsd/libs.mk (working copy) - SYSLIBS += slang + ifneq ($(wildcard /usr/pkg/lib/libslang2.so),) + SYSLIBS += slang2 + else + SYSLIBS += slang + endif this is gross in several ways, but i have no better idea. first grossness is that it has /usr/pkg hardcoded (that path can theoretically be set to anything else upon installing pkgsrc, though i don't know how common it is to change it); second grossness is it being called slang2 (apparently, with pkgsrc, slang1 and slang2 can coexist). -_DET_INC_HEAD := /X11/Xlib.h +_DET_INC_HEAD := /X11/X.h the reason for this is that (again with pkgsrc) you can apparently get in a situation where you have Xlib.h (libx11), but no X.h (xproto). without X.h but with Xlib.h, harbour thinks there is x, tries to compile support for it, and then hell breaks lose. i've checked (both pkgsrc and debian stuff) that xproto depends on libx11, so this seems a safe and fair change. the patch also adds some /usr/pkg locations to det funs (again, pkgsrc) - i suspect this will help netbsd too. hbtest output is below, tested so far as the result is able to compile and link small programs, although it needs some manual intervention by means of having to specify HB_USER_LDFLAGS=-L/usr/pkg/lib (runtime linking is ok). i am not familiar enough with pkgsrc customs to know what to do with it, but i have a hunch that this should be left as-is for the user to set. Index: src/common/hbprintf.c === --- src/common/hbprintf.c (revision 14580) +++ src/common/hbprintf.c (working copy) @@ -163,7 +163,7 @@ # define _x_long_dbl long double # if defined( __WATCOMC__ ) || defined( __MINGW32CE__ ) || defined( __CYGWIN__ ) || \ defined( HB_OS_BEOS ) || defined( HB_OS_IPHONE ) || \ - defined( __OpenBSD__ ) || defined( __NetBSD__ ) || \ + defined( __OpenBSD__ ) || defined( __NetBSD__ ) || defined( __DragonFly__ ) || \ ( defined( HB_OS_WIN_CE ) defined( __POCC__ ) ) #define _HB_WRAP_MODFL_ #define _MODFD( x, p ) _hb_modfl( x, p ) Index: include/hbsetup.h === --- include/hbsetup.h (revision 14580) +++ include/hbsetup.h (working copy) @@ -381,7 +381,7 @@ #ifndef HB_OS_BSD #if defined( __FreeBSD__ ) || defined( __NetBSD__ ) || defined( __OpenBSD__ ) || \ - defined( HB_OS_DARWIN ) + defined( HB_OS_DARWIN ) || defined( __DragonFly__ ) #define HB_OS_BSD #endif #endif Index: config/global.mk === --- config/global.mk(revision 14580) +++ config/global.mk(working copy) @@ -100,6 +100,8 @@ HB_HOST_PLAT := bsd else ifneq ($(findstring bsd,$(1)),) HB_HOST_PLAT := bsd + else ifneq ($(findstring DragonFly,$(1)),) + HB_HOST_PLAT := bsd else ifneq ($(findstring OS/2,$(1)),) HB_HOST_PLAT := os2 else ifneq ($(findstring MS-DOS,$(1)),) Index: config/bsd/libs.mk === --- config/bsd/libs.mk (revision 14580) +++ config/bsd/libs.mk (working copy) @@ -12,7 +12,11 @@ SYSLIBS += $(HB_LIBNAME_CURSES) endif ifneq ($(HB_HAS_SLANG),) - SYSLIBS += slang + ifneq ($(wildcard /usr/pkg/lib/libslang2.so),) + SYSLIBS += slang2 + else + SYSLIBS += slang + endif # In BSD, slang still needs curses :( ifneq ($(HB_HAS_CURSES),) SYSLIBS += $(HB_LIBNAME_CURSES) @@ -23,7 +27,7 @@ SYSLIBPATHS += /usr/X11R6/lib endif - SYSLIBPATHS += /usr/local/lib + SYSLIBPATHS += /usr/local/lib /usr/pkg/lib ifneq ($(HB_HAS_PCRE),) ifeq ($(HB_HAS_PCRE_LOCAL),) Index: config/detect.mk === --- config/detect.mk(revision 14580) +++ config/detect.mk(working copy) @@ -60,7 +60,7 @@ _DET_VAR_HAS_ := HB_HAS_PCRE _DET_FLT_PLAT := _DET_FLT_COMP := -_DET_INC_DEFP := /usr/include /usr/local/include /opt/local/include +_DET_INC_DEFP := /usr/include /usr/local/include /usr/pkg/include /opt/local/include _DET_INC_LOCL := $(realpath $(TOP)$(ROOT)external/pcre) _DET_INC_HEAD := /pcre.h @@ -104,6 +104,7 @@ _DET_INC_DEFP += /usr/local/include /usr/local/include/slang _DET_INC_DEFP += /sw/include /sw/include/slang _DET_INC_DEFP += /opt/local/include /opt/local/include/slang +_DET_INC_DEFP += /usr/pkg/include/slang2 include $(TOP)$(ROOT)config/detfun.mk @@ -130,8 +131,8 @@ _DET_VAR_HAS_ := HB_HAS_X11 _DET_FLT_PLAT := _DET_FLT_COMP := -_DET_INC_DEFP := /usr/include /usr/local/include /usr/X11R6/include -_DET_INC_HEAD := /X11/Xlib.h +_DET_INC_DEFP := /usr/include /usr/local/include
Re: [Harbour] add dragonfly support
On Tue, 25 May 2010, Viktor Szakáts wrote: hi, I've committed, along with hbmk2 patch, so in theory the last issue with HB_USER_LDFLAGS should be fixed. (since the /pkg dir is already hardcoded when checking for slang2, I think it's just fine to also add it to lib list in hbmk2) nice, thanks. let me make a small amendment: - reorg includes so that in case only slang1 is installed, it too can be used, and when both slang1 and slang2 are installed, slang2 is favored (in fact, this is a necessity, since the config/bsd/libs.mk snippet as well as your hbmk2 addition will pick libslang2 up if it is present). gtsln will apparently work with both (lightly tested). again, this should hold true for all pkgsrc platforms (primarily netbsd, apart from dfly, in our case). - it seems i got the x.h/xlib.h thing all mixed up afterall, so revert that. Index: config/detect.mk === --- config/detect.mk(revision 14585) +++ config/detect.mk(working copy) @@ -104,7 +104,7 @@ _DET_INC_DEFP += /usr/local/include /usr/local/include/slang _DET_INC_DEFP += /sw/include /sw/include/slang _DET_INC_DEFP += /opt/local/include /opt/local/include/slang -_DET_INC_DEFP += /usr/pkg/include/slang2 +_DET_INC_DEFP += /usr/pkg/include/slang2 /usr/pkg/include include $(TOP)$(ROOT)config/detfun.mk @@ -132,7 +132,7 @@ _DET_FLT_PLAT := _DET_FLT_COMP := _DET_INC_DEFP := /usr/include /usr/local/include /usr/X11R6/include /usr/pkg/include -_DET_INC_HEAD := /X11/X.h +_DET_INC_HEAD := /X11/Xlib.h include $(TOP)$(ROOT)config/detfun.mk -- [-] mkdir /nonexistentIndex: config/detect.mk === --- config/detect.mk (revision 14585) +++ config/detect.mk (working copy) @@ -104,7 +104,7 @@ _DET_INC_DEFP += /usr/local/include /usr/local/include/slang _DET_INC_DEFP += /sw/include /sw/include/slang _DET_INC_DEFP += /opt/local/include /opt/local/include/slang -_DET_INC_DEFP += /usr/pkg/include/slang2 +_DET_INC_DEFP += /usr/pkg/include/slang2 /usr/pkg/include include $(TOP)$(ROOT)config/detfun.mk @@ -132,7 +132,7 @@ _DET_FLT_PLAT := _DET_FLT_COMP := _DET_INC_DEFP := /usr/include /usr/local/include /usr/X11R6/include /usr/pkg/include -_DET_INC_HEAD := /X11/X.h +_DET_INC_HEAD := /X11/Xlib.h include $(TOP)$(ROOT)config/detfun.mk ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] add dragonfly support
On Tue, 25 May 2010, Tamas TEVESZ wrote: hi, let me make a small amendment: and one more. apparently clang (pkgsrc wip/clang at least) works too. config/bsd/clang.mk is a straight copy of config/linux/clang.mk so i'll spare inlining it. some hbmk2-voodoo is needed in addition to this, of course (will i ever be able to figure that one out). ideally these should be tested on other bsds, but how about calling it work-in-progress and wait for people to give it a try? : -- [-] mkdir /nonexistentIndex: config/bsd/clang.mk === --- config/bsd/clang.mk (revision 0) +++ config/bsd/clang.mk (revision 0) @@ -0,0 +1,60 @@ +# +# $Id: clang.mk 14374 2010-04-22 23:53:45Z vszakats $ +# + +ifeq ($(HB_BUILD_MODE),cpp) + # -ccc-clang-cxx + HB_CMP := clang +else + HB_CMP := clang +endif + +OBJ_EXT := .o +LIB_PREF := lib +LIB_EXT := .a + +HB_DYN_COPT := -DHB_DYNLIB -fpic + +CC := $(HB_CCACHE) $(HB_CCPREFIX)$(HB_CMP)$(HB_CCPOSTFIX) +ifneq ($(filter --analyze, $(HB_USER_CFLAGS)),) + CC_IN := +else + CC_IN := -c +endif +CC_OUT := -o + +CFLAGS += -I. -I$(HB_INC_COMPILE) + +ifneq ($(HB_BUILD_WARN),no) + CFLAGS += -W -Wall +else + CFLAGS += -W +endif + +ifneq ($(HB_BUILD_OPTIM),no) + CFLAGS += -O3 +endif + +ifeq ($(HB_BUILD_DEBUG),yes) + CFLAGS += -g +endif + +LD := $(HB_CCACHE) $(HB_CCPREFIX)$(HB_CMP)$(HB_CCPOSTFIX) +LD_OUT := -o + +LIBPATHS := $(foreach dir,$(LIB_DIR) $(SYSLIBPATHS),-L$(dir)) +LDLIBS := $(foreach lib,$(HB_USER_LIBS) $(LIBS) $(SYSLIBS),-l$(lib)) + +LDFLAGS += $(LIBPATHS) + +AR := $(HB_CCPREFIX)ar +AR_RULE = ( $(AR) $(ARFLAGS) $(HB_AFLAGS) $(HB_USER_AFLAGS) rcs $(LIB_DIR)/$@ $(^F) $(ARSTRIP) ) || ( $(RM) $(LIB_DIR)/$@ false ) + +DY := $(CC) +DFLAGS += -shared $(LIBPATHS) +DY_OUT := -o$(subst x,x, ) +DLIBS := $(foreach lib,$(HB_USER_LIBS) $(SYSLIBS),-l$(lib)) + +DY_RULE = $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ $^ $(DLIBS) $(DYSTRIP) $(LN) $(@F) $(DYN_FILE2) + +include $(TOP)$(ROOT)config/rules.mk ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14591] trunk/harbour
On Tue, 25 May 2010, vszak...@users.sourceforge.net wrote:
2010-05-25 23:40 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
+ config/bsd/clang.mk
+ Base implementation of bsd/clang target.
Based on patch by Tamas Tevesz with modifications:
- deleted HB_DYN_COPT
- replaced dynamic lib rules with bsd/gcc.mk.
(both fully untested)
almost there. it seems that $hb_install_prefix/lib*.so -
$hb_install_prefix/harbour/ links are not being made, for
postinst.sh appears to be not doing a thing.
is it possible that in some shape, way or form something along these
lines is needed?
Index: bin/postinst.sh
===
--- bin/postinst.sh (revision 14593)
+++ bin/postinst.sh (working copy)
@@ -270,7 +270,8 @@
[ $HB_COMPILER = djgpp ] || \
[ $HB_COMPILER = icc ] || \
[ $HB_COMPILER = sunpro ] || \
- [ $HB_COMPILER = open64 ]
+ [ $HB_COMPILER = open64 ] || \
+ [ $HB_COMPILER = clang ]
then
if [ -n ${HB_TOOLS_PREF} ]; then
hb_mkdyn=${HB_INST_PKGPREF}${HB_BIN_INSTALL}/${HB_TOOLS_PREF}-mkdyn
this seems to have fixed this remaining issue here, and hbmk2 is quite
happily churning out clang-compiled binaries.
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14591] trunk/harbour
yOn Wed, 26 May 2010, Tamas TEVESZ wrote: this seems to have fixed this remaining issue here, and hbmk2 is quite happily churning out clang-compiled binaries. yuh, works nicely on freebsd8R-ish with devel/llvm-devel. netbsd decided to show virtualbox the finger, so that's on the back burner for now (but i wouldn't expect any serious problems with it). -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] sunpro-compiled hbrun doesn't work anymore
hi,
as $subject says. i have bisected the problem to have been introduced
in r12466 (r12465 is fine).
r12466 only says segmentation fault, leaving an empty hb_out.log;
r14542 is a bit more verbose with:
Application Internal Error -
/home/ice/w/xhb/hbci/harbour-bisect/harbour/inst/linux/sunpro/c/bin/hbrun
Terminated at: 2010.05.20 22:26:52
Unrecoverable error 6005: Exception SIGSEGV at address 0x1b800ad5268
Called from GET(73)
Called from GETNEW(1978)
Called from __GET(70)
Called from HB_DOTPROMPT(162) in ../../../hbrun.prg
Called from _APPMAIN(124) in ../../../hbrun.prg
(backtraces for both cases are below).
this only happens if hbrun is requested to run interactively (eg.
using the dot console); if it is to run a program (at least a simple
one), it's ok. i also have not been able to find anything similar with
the other compilers i'm testing with.
build environment is ubuntu 10.04/x64 and ubuntu 6.06/i386, with the
following settings:
unset ${!HB_*}
export HB_BUILD_DEBUG=yes
export HB_COMMERCE=yes
export HB_BUILD_OPTIM=no
export HB_CONTRIBLIBS=no
export HB_WITH_PCRE=yes
export HB_WITH_ZLIB=yes
export HB_PLATFORM=linux
export HB_COMPILER=sunpro
export HB_BUILD_MODE=cpp
export HB_INSTALL_PREFIX=$appdir/inst/$HB_PLATFORM/$HB_COMPILER/$HB_BUILD_MODE
(HB_WITH_PCRE and HB_WITH_ZLIB are not present when building head)
sunpro is cc: Sun C 5.10 Linux_i386 2009/06/03 (CC doesn't work for a
while, barfing on some system headers).
here's what gdb has to say about this (this particular one being
ubuntu 10.04/x64; 6.06/i386 is essentially the same, save for the
addresses):
this is the backtrace for r12466, where the problem originally was
introduced:
pinky:~/w/xhb/hbci/harbour-bisect/harbour-r12466$ gdb
./inst/linux/sunpro/c/bin/hbrun
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from
/home/ice/w/xhb/hbci/harbour-bisect/harbour-r12466/inst/linux/sunpro/c/bin/hbrun...done.
(gdb) run
Starting program:
/home/ice/w/xhb/hbci/harbour-bisect/harbour-r12466/inst/linux/sunpro/c/bin/hbrun
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00429ae1 in hb_vmPushStatic (uiStatic=1) at ../../../hvm.c:6960
6960 pStatic = ( ( PHB_ITEM ) hb_stackGetStaticsBase()
)-item.asArray.value-pItems + uiStatic - 1;
(gdb) bt full
#0 0x00429ae1 in hb_vmPushStatic (uiStatic=1) at ../../../hvm.c:6960
pStatic = 0xb6f788
#1 0x004304a2 in hb_xvmPushStatic (uiStatic=1) at ../../../hvm.c:9037
No locals.
#2 0x005cd8fc in HB_FUN_GET () at tget.c:408
fValue = 32767
#3 0x00425c0c in hb_vmProc (uiParams=0) at ../../../hvm.c:5720
sStackState = {lBaseItem = 29, ulPrivateBase = 0, pStatics = 0xb93418,
uiClass = 0, uiMethod = 0, uiLineNo = 73,
fDebugging = 0}
pSym = 0xaf1c60
#4 0x0042fb2d in hb_xvmFunction (uiParams=0) at ../../../hvm.c:8918
No locals.
#5 0x005f538e in HB_FUN_GETNEW () at tget.c:9369
No locals.
#6 0x00425c0c in hb_vmProc (uiParams=5) at ../../../hvm.c:5720
sStackState = {lBaseItem = 21, ulPrivateBase = 0, pStatics = 0xb93418,
uiClass = 0, uiMethod = 0, uiLineNo = 1975,
fDebugging = 0}
pSym = 0xaf3e70
#7 0x0042fb2d in hb_xvmFunction (uiParams=5) at ../../../hvm.c:8918
No locals.
#8 0x005f6690 in HB_FUN___GET () at tgetint.c:124
fValue = 0
#9 0x00425c0c in hb_vmProc (uiParams=5) at ../../../hvm.c:5720
sStackState = {lBaseItem = 6, ulPrivateBase = 0, pStatics = 0xb93418,
uiClass = 0, uiMethod = 0, uiLineNo = 70,
fDebugging = 0}
pSym = 0xad49c8
#10 0x00414fad in hb_vmExecute (pCode=0x80a31e
\f\005\024\002\060\034, pSymbols=0xad4688) at ../../../hvm.c:1629
bCanRecover = 0
bDynCode = 0
piKeyPolls = 0xb4a880
#11 0x00412ac7 in HB_FUN_HB_DOTPROMPT () at hbrun.c:280
pcode =
\r\t\001tJ\000$\210\000\260\r\000\024\000\260\016\000yy\024\002$\211\000\260\017\000\\
Re: [Harbour] sunpro-compiled hbrun doesn't work anymore
On Thu, 20 May 2010, Przemysław Czerpak wrote: hi, Linux SUNPRO port has very serious bug. It does not correctly generate code for all constructors. We are exploiting this problem from time to time. It probably depends on total binary size which may interact with the contents of some uninitialized memory. I do not know exectly where thanks for the explanation. due to this problem. Now I've tested current builds and it works OK. I can executed without any problems hbtest and hbrun. I'm using suse1...@x86_64. Anyhow I expect that it can stop to work in any moment when some modification change total memory alignment and the problem will be exploited again. Looks that in your system is still exploited. strange. it was working fine with the previous, and maybe the one before ubuntus, now it turns out it doesn't work even with a rather older one either. this must either be a stupid one in sunpro, or mean that linux changes frequently :) anyway, thanks for explaining this, let's see what oracle does with the lot (i'm not holding my breath though). -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] several build failures with r13656
hi, i am quite hopelessly behind reading the list, but at a quick skim these have not surfaced yet. linux x dos/watcom c linux x os2/watcom c++ linux x win/mingw c linux x win/mingw c++ linux x win/watcom c linux x win/watcom c++ these builds are broken atm. os2/watcom c++ is: /usr/bin/harbour ../../../achoice.prg -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -gc3 wpp386 -zq -bt=os2 -bm -w3 -3r -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -DHB_HAS_PCRE -I/home/ice/w/xhb/hbci/harbour-build/external/pcre -DPCRE_STATIC -DHB_HAS_ZLIB -I/home/ice/w/xhb/hbci/harbour-build/external/zlib -fo=achoice.obj achoice.c achoice.c(132): Error! E473: col(29) function argument(s) do not match those in prototype achoice.c(132): Note! N392: col(29) definition: 'int hb_xvmPopLogical( int * )' achoice.c(132): Note! N643: col(29) cannot convert argument 1 defined in: achoice.c(132) (col 31) achoice.c(132): Note! N630: col(29) source conversion type is 'unsigned long *' achoice.c(132): Note! N631: col(29) target conversion type is 'int *' [...] the rest are: /usr/bin/harbour ../../../checkbox.prg -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -gc3 ../../../../../include/hbclass.ch(152) Error E0025 Error in #if expression error full build logs for all of the above are attached. -- [-] mkdir /nonexistent buildfails.tar.bz2 Description: Binary data ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] x86 build on amd64 Linux
On Sat, 9 Jan 2010, Viktor Szakáts wrote: HB_USER_CFLAGS=-m32 is a good start (assuming gcc or sunpro), but component autodetection will almost certainly be unusable (it'll pick up stuff for which no 32-bit libs are present). Now that I'm testing it live, it seems I also need to set: HB_USER_LDFLAGS=-m32 HB_USER_DFLAGS=-m32 strange, i have always been under the impression ld can figure these out based on the (input) object format. whatever. Plus I need to install '-32bit' postfixed packages additionally. OpenSUSE seems to support this scenario well. ../../../../../src/vm/obj/linux/gcc/runner_dyn.o ../../../../../src/vm/obj/linux/gcc/vm_dyn.o -lncurses -lslang -lX11 -lz -lrt -ldl -lm -s ln -sf libharbour-2.0.0.so ../../../../../lib/linux/gcc/libharbour.so /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../libX11.so when searching for -lX11 /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/libX11.so when searching for -lX11 /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld: cannot find -lX11 this is because it doesn't find 32bit x11 libs. looking at a 11.2 x64 media, i see no -32bit devel packages for xlibs. So to reiterate, what is the 'official' way to build an 32-bit .rpm on a 64-bit host? that i have never known in the first place ; -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] openSUSE 32-bit build on 64-bit [update#1]
On Sat, 9 Jan 2010, Viktor Szakáts wrote: I'm not sure if it's missing package or something missing from our .mk files. [TOFIX?] As far as I can tell, a libX11.so lib _was_ installed in 32-bit lib dir. This can be solved using this ugly hack: [update#1] $ cd /usr/lib $ sudo ln -s libX11.so.6 libX11.so i personally have feelings against this, but it seems to be in line with the how to compile wine64 on suse document at http://wiki.winehq.org/WineOn64bit, which in it's own right might be useful, given the sort-of similarity of the situation. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] x86 build on amd64 Linux
On Fri, 8 Jan 2010, Viktor Szakáts wrote: hi, What build settings are needed to build an x86 (i?86) Harbour build on an amd64 host? HB_USER_CFLAGS=-m32 is a good start (assuming gcc or sunpro), but component autodetection will almost certainly be unusable (it'll pick up stuff for which no 32-bit libs are present). you'd best do this on centos (fedora too, perhaps -- they ship 32bit versions of most every lib); not a chance it'll (easily) work on debian-ish stuff. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] x86 build on amd64 Linux
On Fri, 8 Jan 2010, Viktor Szakáts wrote: hi, What build settings are needed to build an x86 (i?86) Harbour build on an amd64 host? HB_USER_CFLAGS=-m32 is a good start (assuming gcc or sunpro), but component autodetection will almost certainly be unusable (it'll pick up stuff for which no 32-bit libs are present). you'd best do this on centos (fedora too, perhaps -- they ship 32bit versions of most every lib); not a chance it'll (easily) work on debian-ish stuff. Thanks, I'll have a start with -m32. How is it possible to install 32-bit libs on an 64-bit system? short if compiling by hand... i know of no such way. debian and ubuntu only ships a quite small set of 32-bit libs just enough to run some 32-bit only stuff (adobe reader and the likes). hand-installing so that it is in sync with the system libs (so that you only need one set of headers, thus autodetect won't get fooled)... laborous. Maybe it's also possible to add support for this case in autodetection, but I'm in the dark ATM. with red hat, it's quite simple, as apart from -m32, you don't really need anything else, i think (well, obviously, you need to install both the 32 and 64 bit versions of any given library, but these come with the distro). Switching to 64-bit Ubuntu (the distro I use) is also on the table, but until I'm not sure about these issues, I don't feel comfortable to make it. ubuntu is linux for the masses. the masses don't need anything more complicated than a wooden cube (and even that might be too confusing). if you need anything more complicated than a wooden cube.. go figure ;) if i wanted to do this, i'd first consider something redhat (can't speak for suse at all, though). -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, francesco perillo wrote: harbour-static contains the .a libraries doesn't suse name these kinds of packages -devel, like any rpm system with good manners does? -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, francesco perillo wrote: On Sun, Jan 3, 2010 at 11:20 AM, Tamas TEVESZ i...@extreme.hu wrote: On Sun, 3 Jan 2010, francesco perillo wrote: harbour-static contains the .a libraries doesn't suse name these kinds of packages -devel, like any rpm system with good manners does? Well, I will check with other compiler packages you should be checking the library packages instead. -static means a completely different thing. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, francesco perillo wrote: francesco, honestly this is not intended as an offence, far be from it, but there are established standards and policies for packaging, which you are not to reinvent, override or outsmart, but to follow. opensuse has some nice documentation on packaging at http://en.opensuse.org/Packaging, especially for the currently relevant topic of libraries at http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy note it says packaging policy, not packaging suggestions. proper packaging is much more complicated and tricky business than most of you can even begin to imagine, and it most certainly isn't just lets shovel a metric shitload of files into an rpm (or deb, or anything else, for that matter) container and call it a day. as things stand now, as far as i can tell (this is a long shot, and a premature statement from my side, but hey) the upstream build system and upstream procedures aren't even able to support proper packaging. again, do not take this the wrong way, but it really is a much more complicated matter than most of you seem to think. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
most things below are just scratching the problem-surface, and
definitely need more eyes.
I have a pending commit, which merges core + lib + static
rpms into one. Is this okay?
definitely not.
i think that the proper splitting is something very close to this (as
i'm primarily familiar with deb, that's what i base the following
upon, but the general principle applies with most every distro, and to
some extent ports, pkgsrc, and whatever other packaging method there
is):
harbour-utils - hbrun, maybe hbtest
libharbour$shlib_version - libharbour{mt,}.so.x.y.z
libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to .x.y.z)
harbour - harbour, hbmk2, *.ch, other stuff that are directly used
when compiling prg to native code
harbour-doc - stuff in doc/
libharbour-foo - a foo component with the foo.so.x.y.z
libharbour-foo-dev - headers for this foo.so.x.y.z, and foo.so (link
to foo.so.x.y.z)
of course with carefully crafted dependencies between these, where
internal dependencies between tools and stuff may further change the
scene.
as you can see, there is a lot of the above that is not there in the
build system.
the first problem is a consistent shared library versioning policy.
currently the so version is stuck to the harbour version number, which
is suboptimal. it has had the same version number for quite some time,
with api and maybe abi changes too, this is bad karma. there needs to
be a procedure stating if you change abi in an incompatible way, bump
major; if you change abi in a compatible way, bump minor; if unsure,
bump, or something along these lines.
this is a strict prerequisite for any libharbour package, which in
turn is a strict prerequisite for (other, 3rd party) stuff written in
harbour entering any distro (which i suppose is an implicit goal,
otherwise there's no point in harbour itself entering any distro).
this only covers libharbour, and does not even begin to scratch the
stuff that is currently only shipped in static archives. it seems to
be customary not to make shared versions of these; i haven't yet
figured out whether this is good or bad (i can reason either case,
though :).
yes, this detaches libharbour version from the actual harbour version,
but it also makes it possible (with some extra tweaks i s'pose) to
have several libharbour versions installed, which is good for example
if there is a harbour-2.0 package with the release version, and a
harbour-be (for bleeding edge) version updated regularly, thus
making it possible for a developer (harbour user, who develops in
harbour, but who does not develop harbour) to have a stable
development environment as well as be able to test new features,
follow new features (maybe in a separate branch in her application),
and also report bugs with the development version of harbour.
libharbour also needs some baseline functionality. what this means is
that no matter where, on what system, in what environment, etc etc, is
a libharbour.so.x.y.z is generated, any other libharbour.so with the
same x.y.z version generated on any other system in any other
environment need to have at least a well-defined common ground (call
it core functionality), ideally be the same. what this actually
means is up for definition (eg. what rdds, what gts, etc etc).
optional (everything the above does not cover) is to be supplied in
separate {libraries, archives, ...} maybe by libharbour dlopening them
on demand, or whatever.
consider this: i have application `foobar', it uses
libharbour-4.3.11, and it crashes when i look to the left. the
backtrace says `system has been recalled'. currently basically
there's no way to tell what actually *is* in libharbour-4.3.11, making
debugging in email (which *will* happen, when we're there) nigh
impossible. mix and match this with the currently non-existing
consistent shlib versions, and it quickly translates to hm,
libharbour-4.3.11. we have absolutely no idea what it might be.
then there's the question of packaging the contrib stuff, possibly
creating packages that support cross-compiling (the picture starts to
get blurry now -- see, you don't, for example, package gtwvw for a
native package, but you do for a cross-compile environment).
then there's the question of (again) packaging the contrib stuff - do
we want a separate package for each (i can reason pro and con against
either), or do we want to group them by some attributes (i can reason
pro and con against either) (though my preference is this latter), ...
at this point i literally got tired of citing the issues, as in i
really need a coffee, but i'm pretty much certain that by now everyone
sees that it is _rather a complicated issue_.
We can rename it to anything, although I have to wonder about
these policies... This policy is OpenSUSE specific. Now if each
distro has its own policy (and why not, I bet they have), we
will have some fun waste
Re: [Harbour] SF.net SVN: harbour-project:[13457] trunk/harbour
On Sun, 3 Jan 2010, vszak...@users.sourceforge.net wrote: * harbour.spec + Merged lib and static subpackages into main one. oh, i see you did that while i was away typing. anyway, there's no point in reverting that; currently (by virtue of rpm/deb being used as a convenience container only), as long as the result installs, it completely doesn't matter. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
harbour-utils - hbrun, maybe hbtest
libharbour$shlib_version - libharbour{mt,}.so.x.y.z
libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to .x.y.z)
harbour - harbour, hbmk2, *.ch, other stuff that are directly used
when compiling prg to native code
harbour-doc - stuff in doc/
libharbour-foo - a foo component with the foo.so.x.y.z
libharbour-foo-dev - headers for this foo.so.x.y.z, and foo.so (link
to foo.so.x.y.z)
What is the point of having 'harbour' package, when
nothing useful can be done with it? In any case, hbmk2
needs to be moved to utils since it requires libs to
work.
naturally there are dependencies between them, also external deps as
needed.
Then what is the point of having hbrun without dynamic
libs, when hbrun is built as shared binary in certain
situations, so it cannot work without Harbour dynamic
lib also.
i might be misunderstanding something, but this seems to be untrue. i
have a hbrun binary that (to a certain extent) chugs along nicely,
without any trace of a dynamic libharbour (or anything else harbour)
being around anywhere.
I think the ultimate difference between Harbour and
regular 'lib' packages, is that in Harbour there is
not much point in having a dev packages, as development
consists of building final apps in 99.99% of cases,
and not building something else with the help of Harbour
headers.
hbrun's script interpreter mode is the prime example of the contrary.
also imagine przemek coming up with (arbitrary example) an ads-like
dbf server, which relies on and only relies on libhb (file
management, network management, dbf drivers, full stop). should the
compiler and headers, and contrib/rddads be installed in this case?
hardly.
harbour compiler executable can do very little thing
by itself, as far as real-life usage goes.
Here comes to mind, that maybe we should also list
C compiler tools as dependency, because without C
compiler, Harbour is again unusable.
yes, of course. i deliberately didn't go into such details for fear of
being lost in them.
the first problem is a consistent shared library versioning policy.
currently the so version is stuck to the harbour version number, which
is suboptimal. it has had the same version number for quite some time,
with api and maybe abi changes too, this is bad karma. there needs to
We've been in development stage. Version in increased
by each major release, and we promise to keep compatibility
between minor releases only. Emphasis on _release_. Current
SVN, beta, or rc isn't a release.
ok, i accept that. i still think that bumping as changes go would be
better, but i accept that.
this only covers libharbour, and does not even begin to scratch the
stuff that is currently only shipped in static archives. it seems to
be customary not to make shared versions of these; i haven't yet
figured out whether this is good or bad (i can reason either case,
though :).
Yes, shared lib creation for contribs is not implemented
(yet?).
i feel they also should be, but this also raises libver questions. do
they live a separate life, or do we go with one and only one version
for the whole shebang?
have several libharbour versions installed, which is good for example
if there is a harbour-2.0 package with the release version, and a
harbour-be (for bleeding edge) version updated regularly, thus
making it possible for a developer (harbour user, who develops in
harbour, but who does not develop harbour) to have a stable
development environment as well as be able to test new features,
follow new features (maybe in a separate branch in her application),
and also report bugs with the development version of harbour.
This is only possible in pure dynamic world I guess.
certainly. in a static world, none of this thread applies at all. in
that case, any harbour package is only used by a developer
(application developer writing prg code, producing executables that
only (dyn)link against stuff outside harbour), thus making the whole
proper package idea moot at best, as any package becomes just a
convenience container, for which the current setup is ok. won't ever
enter any distro, but if no end-user is ever to use it, then it
doesn't matter either.
libharbour also needs some baseline functionality. what this means is
that no matter where, on what system, in what environment, etc etc, is
a libharbour.so.x.y.z is generated, any other libharbour.so with the
same x.y.z version generated on any other system in any other
environment need to have at least a well-defined common ground (call
it core functionality), ideally be the same. what this actually
means is up for definition (eg. what rdds, what gts, etc etc).
I'd personally define get Harbour lib version as the only
core
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, Viktor Szakáts wrote: Then what is the point of having hbrun without dynamic libs, when hbrun is built as shared binary in certain situations, so it cannot work without Harbour dynamic lib also. i might be misunderstanding something, but this seems to be untrue. i have a hbrun binary that (to a certain extent) chugs along nicely, without any trace of a dynamic libharbour (or anything else harbour) being around anywhere. It depends on the setup. For cases where Harbour is built to be installed in system locations, the binaries are built against the shared lib. so it is controlled by some heuristics mechanism, i couldn't quickly find where this is. i suppose it has to do with known sysloc paths. building the deb n stuff it looks like: ! HB_BIN_INSTALL: /usr/bin ! HB_LIB_INSTALL: /usr/lib/harbour ! HB_INC_INSTALL: /usr/include/harbour ! HB_DOC_INSTALL: /usr/share/doc/harbour ! HB_INSTALL_PREFIX automatically set to: /usr/local this might be it. install locations are explicitly set, but setting install_prefix doesn't take these into account, and is also set to a non-system loc, which in turn somehow controls dyn builds. it is generally not acceptable to ship packages like this. especially if there is a shared lib, then it shall be used by applications. I think the ultimate difference between Harbour and regular 'lib' packages, is that in Harbour there is not much point in having a dev packages, as development consists of building final apps in 99.99% of cases, and not building something else with the help of Harbour headers. hbrun's script interpreter mode is the prime example of the contrary. also imagine przemek coming up with (arbitrary example) an ads-like dbf server, which relies on and only relies on libhb (file That's true, although hbrun is _not_ part of the default core package we're talking about. hbrun however, requires shared lib. management, network management, dbf drivers, full stop). should the compiler and headers, and contrib/rddads be installed in this case? hardly. Well, standalone apps built using Harbour and part of Harbour package can be like that (like hbrun), but I think this projects primary goal is to build a compiler, and even hbrun may need .ch header and even such dbf server is most likely to have a client side, which will in turn need the compiler. What you describe fits the 'harbour-tool' category, which is fine. So to reiterate, maybe a harbour-dynlibs package, and a harbour-staticlibs package are justified, but this to me feels like breaking the principle of least surprise. what is in harbour-dynlibs would be called libharbour-dev by convention (watch me cheat, it would be called harbour-devel in rpm-land :), but the principle of separation still is the same); similarly, harbour-statislibs would be harbour-dev; although i agree that the fact that there is a runtime and also a compiler is provided by hb makes this a little special. maybe so that libharbour has the shared objects, libharbour-dev has the static archives and the headers. are ch needed when only using an app linked against libharbour? if yes, and for example hbrun needs that, tools can be made to depend on -dev. harbour would then have the compiler, pp and the rest of the gang. libhb is the base of all stuff. hbrun pulls libhb-dev, harbour pulls in hbrun (and lets hbrun implicitly pull libhb-dev). what existing package might be similar to this that could be studied for some inspiration? i can't really think of any now. only as long as these are always pulled by harbour-core package. harbour-tools package would only pull harbour-dynlibs. i feel they also should be, but this also raises libver questions. do they live a separate life, or do we go with one and only one version for the whole shebang? Since they are meant as separate entities, we should have the option to untie they versioning from core anytime. Until they live inside the same repository, we should sync their version to core. it just dawned on me that there also is hbide, which for the moment lives in contrib yes, but is shortly (for an arbitrary definition of short) is expected to enter core, so i think we also should take a harbour-ide package into consideration right at the beginning. i'd rather prefer it not be made part of dev. As for the expected _set of content_, I agree we should have a standard defined, and it's defined well already. It's roughly everything inside /src except compiler. We call this flat out can not be true ;) if you have slang-dev installed and i don't, you get a libharbour with gtslang, i get one without. same sources, system-dependent result. I you ask me, I wanted to pull out gtcrs and gtsln from inside the core for somewhat similar reasons, but it got
Re: [Harbour] SF.net SVN: harbour-project:[13436] trunk/harbour
On Sat, 2 Jan 2010, vszak...@users.sourceforge.net wrote: hi, * config/global.mk + Added rudamentary package manager detection (so far for darwin and linux). Please extend. This will allow to make proper dependency checking in detect.mk. the deb heuristics are quite wrong (works on latest ubuntu, but that's about it. maybe one version back as well.). you should rather check for the existence of /etc/debian_version, that's a much better sign of dpkg being the native package manager. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13437] trunk/harbour
On Sat, 2 Jan 2010, vszak...@users.sourceforge.net wrote: * config/global.mk ! Fixed debian package manager detection, as suggest by Tamas Tevesz. you nicely beat me to it while i was preoccupied ;) the floowing (also attached) could also be applied for uniformity. Index: config/global.mk === --- config/global.mk(revision 13437) +++ config/global.mk(working copy) @@ -507,10 +507,10 @@ # try to detect MinGW cross-compiler location using some default platform settings ifeq ($(HB_CCPATH)$(HB_CCPREFIX),) - ifneq ($(call find_in_path_raw,debian_version,/etc),) + ifneq ($(wildcard /etc/debian_version),) HB_CCPREFIX := i586-mingw32msvc- else - ifneq ($(call find_in_path_raw,gentoo-release,/etc),) + ifneq ($(wildcard /etc/gentoo-release),) ifneq ($(call find_in_path_par,i386-mingw32msvc-gcc,/opt/xmingw/bin),) HB_CCPATH := /opt/xmingw/ HB_CCPREFIX := i386-mingw32msvc- -- [-] mkdir /nonexistentIndex: config/global.mk === --- config/global.mk (revision 13437) +++ config/global.mk (working copy) @@ -507,10 +507,10 @@ # try to detect MinGW cross-compiler location using some default platform settings ifeq ($(HB_CCPATH)$(HB_CCPREFIX),) - ifneq ($(call find_in_path_raw,debian_version,/etc),) + ifneq ($(wildcard /etc/debian_version),) HB_CCPREFIX := i586-mingw32msvc- else - ifneq ($(call find_in_path_raw,gentoo-release,/etc),) + ifneq ($(wildcard /etc/gentoo-release),) ifneq ($(call find_in_path_par,i386-mingw32msvc-gcc,/opt/xmingw/bin),) HB_CCPATH := /opt/xmingw/ HB_CCPREFIX := i386-mingw32msvc- ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] simplifying global.mk
On Sat, 2 Jan 2010, Viktor Szakáts wrote: hi, No, it looks fine. It can even be a little bit further optimized, I'll commit it ASAP, pls test it. works nicely. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] simplifying global.mk
one more related cleanup piece Index: config/dir.mk === --- config/dir.mk (revision 13444) +++ config/dir.mk (working copy) @@ -10,11 +10,6 @@ ifeq ($(HB_HOST_PLAT),dos) # do not use rules for parallel processing in DOS JOB_SRV := NO -else - # these make versions does not work correctly with - # parallel execution rules below - JOB_SRV := $(MAKE_VERSION:3.7%=NO) - JOB_SRV := $(JOB_SRV:3.80%=NO) endif ifeq ($(JOB_SRV),NO) -- [-] mkdir /nonexistentIndex: config/dir.mk === --- config/dir.mk (revision 13444) +++ config/dir.mk (working copy) @@ -10,11 +10,6 @@ ifeq ($(HB_HOST_PLAT),dos) # do not use rules for parallel processing in DOS JOB_SRV := NO -else - # these make versions does not work correctly with - # parallel execution rules below - JOB_SRV := $(MAKE_VERSION:3.7%=NO) - JOB_SRV := $(JOB_SRV:3.80%=NO) endif ifeq ($(JOB_SRV),NO) ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 linux release search a releaser
On Sat, 2 Jan 2010, francesco perillo wrote: Another option would be to have the packages split: the first one, monolithic, is the base package, the mandatory one. All the optional packages have the base package as pre-requisite and each one has its own client pre-requistite... a bit like the php packaging... So every user may install the base package and the install only the optional that he needs it's quite obvious that this is the long-term way to go :) i have a mail cooking for quite some time, primarily as some kind of feedback to viktor's oft-asked question as to make harbour packaging-friendly, but the whole splitting- and packaging-idea raises so many questions and problems that thus far i've never had the inspiration to sit tight long enough to organize my thoughts and actually write the mail. maybe my unconscious is thinking if i wait long enough, it writes itself :) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] What about evolve harbour name?
On Thu, 31 Dec 2009, Massimo Belgrano wrote: What about evolve harbour name HarbourPro pro Is for a professiona product it is already there. on top of that, ject has been added for **EVEN MORE** professionalism. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Przemysław Czerpak wrote: hi, on platforms where available, what is the significance of including ieeefp.h, given that even without it, things seem to be doing OK? Probably nothing though sometimes is good to check the details in platform documentation. It's possible that in ieeefp.h some functionality is extended, i.e. some math functions from math.h can be replaced by C99 compatible macros which can operate on any floating point types. so, if available, using these is desirable? i'm asking because looking at current src/rtl/math.c, except for a few specific cases, isinf() is used: 334 # if defined( HB_OS_SUNOS ) 335 else if( !finite( dResult ) ) 336 # elif defined( HB_OS_OS2 ) 337 else if( !isfinite( dResult ) ) 338 # else 339 else if( isinf( dResult ) ) 340 # endif at the same time, looking at the solaris manuals for finite(), isinf() and finite() here (won't have access to my sol box till next year): http://docs.sun.com/app/docs/doc/819-2246/isinf-3m?l=Jaa=view http://docs.sun.com/app/docs/doc/819-2246/isfinite-3m?l=Jaa=view http://docs.sun.com/app/docs/doc/801-6680-03/6i11qck75?a=view it seems that the currently special-cased finite() for hb_os_sunos specifically fits your above explanation less than as if it was to let use isinf() as well. i may very well be misunderstanding you, though.. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Przemysław Czerpak wrote: hi, sorry to be so blunt, but the more i read, the less i understand ;) isinf() and isfinite() are C99 extensions so they are not available if C99 features are not enabled. There is problem with non GCC unix builds - they do not use HB_MATH_ERRNO handler (I'll fix it in next commit) and it's the reason why current src/rtl/math.c. do not need ieeefp.h. ok, so there are two places where this is used, in src/rtl/math.c:334 onwards and src/vm/itemapi.c:2250 onwards. they are even used for the same purpose, to check whether or not to signal a range error of sorts on a numeric argument. yet the one in itemapi.c is a macro with a screenful of tests for platforms and compilers and whatnot, whereas the one in math.c is a very simple conditional for os2-sunos-all-the-rest. notably, it doesn't have a special case for os/2 -- nb i do not know if defined( __RSXNT__ ) || defined( __EMX__ ) covers _all_ of os2; if it does, then scratch this last remark, but then the notation is inconstent. why is this difference? (i probably should have picked something less hardcore...) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] two small portability enhancements
hi,
the attached and below inlined does the following:
- hunk #1 prepares for when IPV6_ADD_MEMBERSHIP is defined by the
system; it is very synonymous with IPV6_JOIN_GROUP.
- hunk #2 makes initseg startup work with coff executables. (ok,
despite the heritage, i really don't know whether this includes pe
too :)
for #2, it might be that a simpler solution exists (macro-wise), but i
am not smart enough to have that figured out.
Index: src/rtl/hbsocket.c
===
--- src/rtl/hbsocket.c (revision 13390)
+++ src/rtl/hbsocket.c (working copy)
@@ -2484,6 +2484,9 @@
if( err 0 )
{
mreq.ipv6mr_interface = 0;
+#if !defined( IPV6_JOIN_GROUP ) defined( IPV6_ADD_MEMBERSHIP )
+# define IPV6_JOIN_GROUP IPV6_ADD_MEMBERSHIP
+#endif
ret = setsockopt( sd, IPPROTO_IPV6, IPV6_JOIN_GROUP, ( const char * )
mreq, sizeof( mreq ) );
hb_socketSetOsError( ret != -1 ? 0 : HB_SOCK_GETERROR() );
return ret;
Index: include/hbinit.h
===
--- include/hbinit.h(revision 13390)
+++ include/hbinit.h(working copy)
@@ -136,13 +136,20 @@
static void func( void ) \
{
- #define HB_CALL_ON_STARTUP_END( func ) \
- } \
- HB_INIT_FUNCTION_REF( func ) \
- HB_EXTERN_END \
- asm ( .section .init\n\tcall HB_MACRO2STRING( func ) \n\t.section
.text\n\t );
+ #if defined( _M_COFF )
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( .section .init, \x\\n\tcall HB_MACRO2STRING( func )
\n\t.section .text\n\t );
+ #else
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( .section .init\n\tcall HB_MACRO2STRING( func ) \n\t.section
.text\n\t );
+ #endif
-
#define HB_INIT_FUNCTION_REF( func )\
extern void * func##_ref_( void ); \
void * func##_ref_( void ) \
--
[-]
mkdir /nonexistentIndex: src/rtl/hbsocket.c
===
--- src/rtl/hbsocket.c (revision 13390)
+++ src/rtl/hbsocket.c (working copy)
@@ -2484,6 +2484,9 @@
if( err 0 )
{
mreq.ipv6mr_interface = 0;
+#if !defined( IPV6_JOIN_GROUP ) defined( IPV6_ADD_MEMBERSHIP )
+# define IPV6_JOIN_GROUP IPV6_ADD_MEMBERSHIP
+#endif
ret = setsockopt( sd, IPPROTO_IPV6, IPV6_JOIN_GROUP, ( const char * ) mreq, sizeof( mreq ) );
hb_socketSetOsError( ret != -1 ? 0 : HB_SOCK_GETERROR() );
return ret;
Index: include/hbinit.h
===
--- include/hbinit.h (revision 13390)
+++ include/hbinit.h (working copy)
@@ -136,13 +136,20 @@
static void func( void ) \
{
- #define HB_CALL_ON_STARTUP_END( func ) \
- } \
- HB_INIT_FUNCTION_REF( func ) \
- HB_EXTERN_END \
- asm ( .section .init\n\tcall HB_MACRO2STRING( func ) \n\t.section .text\n\t );
+ #if defined( _M_COFF )
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( .section .init, \x\\n\tcall HB_MACRO2STRING( func ) \n\t.section .text\n\t );
+ #else
+ #define HB_CALL_ON_STARTUP_END( func ) \
+ } \
+ HB_INIT_FUNCTION_REF( func ) \
+ HB_EXTERN_END \
+ asm ( .section .init\n\tcall HB_MACRO2STRING( func ) \n\t.section .text\n\t );
+ #endif
-
#define HB_INIT_FUNCTION_REF( func )\
extern void * func##_ref_( void ); \
void * func##_ref_( void ) \
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] some dependency problem in hbffind.c
hi, preparing a platform that has no S_IFSOCK/S_ISSOCK, i protected the hb alikes like this: include/hbapifs.h: #if defined( S_ISSOCK ) # define HB_FA_SOCKET HB_FA_SPARSE /* S_ISSOCK() */ #endif src/common/hbffind.c: #if defined( S_ISSOCK ) if( S_ISSOCK( raw_attr ) ) ulAttr |= HB_FA_SOCKET; #endif this, on a platform that does have S_ISSOCK, results in cc -DHB_OS_OPENSERVER6 -I. -I../../../../../include -K udk -K pthread -o hbffind.o -c ../../../hbffind.c UX:acomp: ERROR: ../../../hbffind.c, line 246: undefined symbol: HB_FA_SOCKET UX:acomp: ERROR: ../../../hbffind.c, line 318: undefined symbol: HB_FA_SOCKET this seems to be correct, since hbapifs.h doesn't (directly or indirectly) include sys/stat.h, thus has no knowledge of macros/flags actually defined in the system. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
On Tue, 22 Dec 2009, Viktor Szakáts wrote: I'm glad to announce that after a very heavy 16 months of development, the final, stable version 2.0.0 is finally released. incredible job! a toast a cheers to all those involved! -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] unify TODOs/iTODOs
hi,
the attached unifies all int TODOs to int iTODOs, for your
grepping pleasure.
--
[-]
mkdir /nonexistentIndex: src/vm/thread.c
===
--- src/vm/thread.c (revision 13370)
+++ src/vm/thread.c (working copy)
@@ -786,7 +786,7 @@
*th_id = _beginthread( start_func, NULL, 128 * 1024, Cargo );
th_h = *th_id;
#else
- { int TODO_MT; }
+ { int iTODO_MT; }
*th_id = ( HB_THREAD_ID ) 0;
th_h = ( HB_THREAD_HANDLE ) 0;
#endif
@@ -818,7 +818,7 @@
*/
return rc == NO_ERROR || rc == ERROR_INVALID_THREADID;
#else
- { int TODO_MT; }
+ { int iTODO_MT; }
return FALSE;
#endif
}
@@ -839,7 +839,7 @@
APIRET rc = DosWaitThread( th_h, DCWW_NOWAIT );
return rc == NO_ERROR || rc == ERROR_INVALID_THREADID;
#else
- { int TODO_MT; }
+ { int iTODO_MT; }
return FALSE;
#endif
}
Index: src/vm/dynlibhb.c
===
--- src/vm/dynlibhb.c (revision 13370)
+++ src/vm/dynlibhb.c (working copy)
@@ -130,7 +130,7 @@
hDynLib = ( void * ) dlopen( hb_parc( 1 ), RTLD_LAZY | RTLD_GLOBAL );
#else
{
-int TODO;
+int iTODO;
}
#endif
/* set real marker */
Index: src/common/hbgete.c
===
--- src/common/hbgete.c (revision 13370)
+++ src/common/hbgete.c (working copy)
@@ -233,7 +233,7 @@
* to the above #elif ... to eliminate warning [druzus]
*/
- int TODO;
+ int iTODO;
HB_SYMBOL_UNUSED( szName );
HB_SYMBOL_UNUSED( szValue );
Index: src/common/hbffind.c
===
--- src/common/hbffind.c (revision 13370)
+++ src/common/hbffind.c (working copy)
@@ -712,7 +712,7 @@
#else
{
- int TODO; /* TODO: for given platform */
+ int iTODO; /* TODO: for given platform */
/* HB_SYMBOL_UNUSED( ffind ); */
@@ -865,7 +865,7 @@
{
/* Intentionally do nothing */
-int TODO; /* TODO: for given platform */
+int iTODO; /* TODO: for given platform */
HB_SYMBOL_UNUSED( info );
}
Index: src/common/hbfsapi.c
===
--- src/common/hbfsapi.c (revision 13370)
+++ src/common/hbfsapi.c (working copy)
@@ -330,7 +330,7 @@
}
#else
{
- int TODO; /* To force warning */
+ int iTODO; /* To force warning */
fExist = FALSE;
}
@@ -393,7 +393,7 @@
}
#else
{
- int TODO; /* To force warning */
+ int iTODO; /* To force warning */
fExist = FALSE;
}
@@ -455,7 +455,7 @@
}
#else
{
- int TODO; /* To force warning */
+ int iTODO; /* To force warning */
fExist = FALSE;
}
Index: src/rtl/gtstd/gtstd.c
===
--- src/rtl/gtstd/gtstd.c (revision 13370)
+++ src/rtl/gtstd/gtstd.c (working copy)
@@ -407,7 +407,7 @@
}
#else
{
- int TODO; /* TODO: */
+ int iTODO; /* TODO: */
}
#endif
Index: src/rtl/hbsocket.c
===
--- src/rtl/hbsocket.c (revision 13370)
+++ src/rtl/hbsocket.c (working copy)
@@ -1627,7 +1627,7 @@
#elif defined( IN6ADDR_ANY_INIT )
memcpy( sa.sin6_addr, s_in6addr_any, sizeof( struct in6_addr ) );
#else
- int TODO;
+ int iTODO;
#endif
*pSockAddr = memcpy( hb_xgrab( sizeof( sa ) + 1 ), sa, sizeof( sa ) );
*puiLen = ( unsigned ) sizeof( sa );
@@ -1648,7 +1648,7 @@
else
hb_socketSetRawError( HB_SOCKET_ERR_AFNOSUPPORT );
#else
- int TODO;
+ int iTODO;
#endif
}
#else
@@ -1699,7 +1699,7 @@
szAddr = inet_ntop( AF_INET, sa-sin6_addr, buf, sizeof( buf ) );
# else
{
- int TODO;
+ int iTODO;
szAddr = NULL;
}
# endif
@@ -1853,7 +1853,7 @@
szAddr = inet_ntop( AF_INET, sa-sin6_addr, buf, sizeof( buf ) );
# else
{
- int TODO;
+ int iTODO;
szAddr = NULL;
}
# endif
@@ -2367,7 +2367,7 @@
if( ret == 0 )
ret = 1;
#else
- int TODO;
+ int iTODO;
HB_SYMBOL_UNUSED( sd );
HB_SYMBOL_UNUSED( fBlocking );
hb_socketSetRawError( HB_SOCKET_ERR_NOSUPPORT );
@@ -2391,7 +2391,7 @@
ret = setsockopt( sd, IPPROTO_TCP, TCP_NODELAY, ( const char * ) val, sizeof( val ) );
hb_socketSetOsError( ret != -1 ? 0 : HB_SOCK_GETERROR() );
#else
- int TODO;
+ int iTODO;
HB_SYMBOL_UNUSED( sd );
HB_SYMBOL_UNUSED( fNoDelay );
hb_socketSetRawError( HB_SOCKET_ERR_NOSUPPORT );
@@ -2472,7 +2472,7 @@
hb_socketSetOsError( ret != -1 ? 0 : HB_SOCK_GETERROR() );
return ret;
#else
- int TODO;
+ int iTODO;
#endif
}
#if defined( HB_HAS_INET6 )
@@ -2494,7 +2494,7 @@
[Harbour] ieeefp.h - what's the significance?
hi, on platforms where available, what is the significance of including ieeefp.h, given that even without it, things seem to be doing OK? thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Tagging 2.0.0: Tomorrow
On Mon, 21 Dec 2009, Viktor Szakáts wrote: hi, start making test builds on various platforms, so my batch looks fine (linux host to dos/watcom, os2/watcom, win/watcom, win/mingw, linux/watcom, linux/gcc, linux/sunpro, linux/gcc, both c and cpp; linux/sunpro/cpp is unknown (because of recent header changes in glibc, which sunproCC didn't yet follow)). -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Any commits/fixes pending?
On Sat, 19 Dec 2009, Viktor Szakáts wrote: hi, I'd like to ask everyone if there are any patches, commits or fixes pending? (besides hbqt related modules) this should worth a yes/no/after release: Message-ID: alpine.deb.2.00.0912160438580.27...@dawn.royalcomp.hu or alternatively http://old.nabble.com/g%2B%2B2.95-g%2B%2B3.3-bad-build-td26806223.html considering that currently all g++ v4 builds are broken, the answer should be a yes, though :) (gcc 2.95 is omnipresent on less-than-mainstream-but-still-important platforms, so compatibility with that should be a quite high priority.) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Any commits/fixes pending?
On Sat, 19 Dec 2009, Viktor Szakáts wrote: considering that currently all g++ v4 builds are broken, the answer should be a yes, though :) (gcc 2.95 is omnipresent on less-than-mainstream-but-still-important platforms, so compatibility with that should be a quite high priority.) Probably yes, especially since lot of ppl still use 3.4.x even on Windows, although it's only a real problem if someone is using 3.4.x with QT 4.5.x, even then it's currently not fatal as HBQT uses an empty init/exit routine ATM. I don't know though how grave the problem is, so, if it's not an easy fix, I think can live with that issue until next it's an easy one (switch g++ to static startup), in fact przemek has just included this in his list 3 minutes before i sent my mail, so i consider this taken are of -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Fri, 18 Dec 2009, Przemysław Czerpak wrote: hi, I cannot replicate it (probably because I cannot exactly replicate your environment settings) so I have to guess but probably you are right. Anyhow thank you very much for your tests. Finally I've found a while to clean the selection code in GTXWC. thank you! -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] r13300 xbp build failure
hi, ../../../../../bin/linux/gcc/harbour ../../../xbpwindow.prg -I../../../../../contrib/hbqt -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l ../../../xbpwindow.prg(785) Warning W0032 Variable 'LSUCCESS' is assigned but not used in function 'XBPWINDOW_DESTROY(0)' ../../../xbpwindow.prg(800) Warning W0032 Variable 'LSUCCESS' is assigned but not used in function 'XBPWINDOW_DISCONNECT(0)' -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Przemysław Czerpak wrote: hi, the symptom is that when there is already data in the primary when this app is started, the first inkey(0) is immediately satisfied (and then it shows the correct content for the primary selection). this doesn't happen absolutely always, but it does most of the time. if the primary is empty at app startup, then it never happens. this one is solved,, thank you. so the guess it that *something* is there that causes clients to exit unexpectedly. it is not even sure that the client that exits is the this one is not. Your VM crashes when selection owner does not response. I'll add code to disable own selection in GTXWC exit phase and I hope it will help anyhow real fix should be done in WM code because your description suggests that it may have very serious problems and even crash if selection owner terminates suddenly without clearing the selection i.e. due to delivered asynchronous signal (killall myapp). thanks for the explanation. never mind about the second issue just yet, i will bring it up with wm people. thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Fri, 18 Dec 2009, Przemysław Czerpak wrote: hi, Can you check if problem can be resolved if you add at the end of your test application: hb_gtInfo( HB_GTI_CLIPBOARDDATA, ) no, but i managed to strace the xterm that got picked by the Client Killer Phenomenon. it's last breath was this: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 2 (X_ChangeWindowAttributes) Resource id in failed request: 0x560001e Serial number of failed request: 1107 Current serial number in output stream: 1108 at another try i attached xev to the victim: this is when focus leaves the client so i can push buttons in my text app (using sloppy focus): FocusOut event, serial 17, synthetic NO, window 0x5af, mode NotifyNormal, detail NotifyNonlinear this is when my test app has exited, and i focus the victim client again. all the next events happen in a very short time right after the pointer enters the client area: FocusIn event, serial 17, synthetic NO, window 0x5af, mode NotifyNormal, detail NotifyNonlinear KeymapNotify event, serial 17, synthetic NO, window 0x0, keys: 4294967177 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 these two above events happen normally when any client gets the focus. the below events are what seem to be coming unwanted: UnmapNotify event, serial 17, synthetic NO, window 0x5af, event 0x5af, window 0x5af, from_configure NO FocusOut event, serial 17, synthetic NO, window 0x5af, mode NotifyNormal, detail NotifyAncestor DestroyNotify event, serial 17, synthetic NO, window 0x5af, event 0x5af, window 0x5a0001a DestroyNotify event, serial 17, synthetic NO, window 0x5af, event 0x5af, window 0x5af i have just found that i've been running wm with logs saved all along the way, and i can confirm from those logs that xterms have been dying with the same message during all this experiment. even more interesting. its _only_ the xterms. i have now tried having other apps killed by this method, but it's always the xterm that dies. ok, i have found a pattern i seem to be able to reliably reproduce. i am running XTerm(235) (ubuntu intrepid x64). the test app is on a remote box, which is ubuntu karmic x64. ssh in, start the test app (it doesn't matter whether x is via ssh or via a direct connection). when the test app says to copy something in, copy something in from an xterm. then push through the test app, and after it exits, give focus to the xterm you have copied from (this may need to be done several times). i could kill the xterm in at most 5 tries (of giving it focus, and taking focus away from it). i've tried other apps, xlib-based, xaw-based, gtk-based, i've even tried rxvt, but it is invariably the xterm that dies. i have tried XTerm(243) (this is the latest in ubuntu), same effect. i've built myself a smokin' fresh XTerm(253), same effect. so thus far every finger points at either xterm or xterm-wm interaction being somehow at fault, and we could have been chasing ghosts... -- [-] mkdir /nonexistent ___ 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] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Viktor Szakáts wrote: hi, No educated bug report, but just now I tried to coppy/paste some text from OS X Mail to my app running GTXWC, and the app just hung with 100% CPU consumption. i notice i cannot paste (nor copy) to/from xwc at all ;) anyway, if seems that XWC_DEBUG activates a whole lot of clipboard-related debug stuff, do you get any clue with that? (how is copy-pasting w/ xwc supposed to work? just like any other x app i'd like to hope but still asking, point mouse, click, hold/point mouse, hit middle button?) -- [-] mkdir /nonexistent ___ 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, 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
Re: [Harbour] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Viktor Szakáts wrote: No educated bug report, but just now I tried to coppy/paste some text from OS X Mail to my app running GTXWC, and the app just hung with 100% CPU consumption. this is a long shot, but. is this even supposed to work? i do not know the level of integration of x11 in osx, but there could be problems (there certainly have been in the past, according to my friend google). can you copy and paste between other x11 apps and native apps? say, something like abiword and whatever-notepad-is-on-osx (but anyhow do not use xterm and terminal.app for these tests). you should try selecting (with the mouse, just selecting, nothing else) in abiword, and pasting in $notepad; selecting and edit-copy in abiword, pasting in $notepad. this copy-paste thing in x11 is pretty much unlike anything else. there are two places something can end up, a primary selection (this gets stuff if you select text in an xterm, for example -- this is sort of an implicit buffer), and a clipboard selection (this gets stuff if you explicitly copy in something, by means of edit-copy in an application). far as i can tell, gtxwc plays it safe and always updates both selections (this does seem to work well), so it could well be an integration issue on osx? trying it with an independent x app could reveal what might be wrong. there's a very condensed page about this whole business at http://www.jwz.org/doc/x-cut-and-paste.html anyway, if seems that XWC_DEBUG activates a whole lot of clipboard-related debug stuff, do you get any clue with that? I didn't try that yet, for that I'll need to rebuild everything, which is not option these days. turns out it doesn't worth it without some more surgery. with XWC_DEBUG, it just gets so overly verbose no way to cherrypick the relevant piece anyway :) (how is copy-pasting w/ xwc supposed to work? just like any other x app i'd like to hope but still asking, point mouse, click, hold/point mouse, hit middle button?) This application use hb_gtInfo( HB_GTI_CLIPBOARDDATA ) to copy and paste on all platforms/GTs. It works alright in GTWIN and GTWVT. this seems to be working fine on linux, well almost. this (as far as i can tell) seems intentional in gtxwc.c:3072, but it's as if the selections were cleared by this as well (so anything i have in primary when an xwc app starts, hb_gtInfo( HB_GTI_CLIPBOARDDATA ) will return empty -- this is somewhat surprising, but its not to say this is a huge problem or something). -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] very strange compile error
hi,
while doing a new port, came across this:
g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W
-O3 -o expropt1.o -c ../../../expropt1.c
../../../expropt1.c: In function `struct HB_EXPR_ *
hb_compExprNewNegate(HB_EXPR_ *, _HB_COMMON *)':
../../../expropt1.c:1066: integer constant out of range
this only happens with g++. 2.95 is the only one there is, and it is
entirely possible it is a compiler error, as it has other deficiencies
it theoretically shouldn't.
the absolute minimal example that triggers the problem is:
$ cat y.c
#include limits.h
#include stdio.h
int main( void )
{
printf(%lld\n, LLONG_MAX);
return 0;
}
$ cc y.c
$ ./a.out
9223372036854775807
$ CC y.c
$ ./a.out
9223372036854775807
$ gcc y.c
$ ./a.out
9223372036854775807
$ g++ y.c
y.c: In function `int main()':
y.c:7: integer constant out of range
$
gcc version 2.95.3pl1 d - 20020710 (build) - OU8.0.1
does anyone perhaps have any idea?
thanks,
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Przemysław Czerpak wrote: hi, I've just checked and same OS X GTXWC app picked what was placed to clipboard before starting the app (or even starting X11 for that matter). I'll keep an open eye to report any clipboard problems here. Please try it after: 2009-12-17 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) it is better now, in the sense that now the primary is retained and can be reliably read by hb, but a small artifact remains. i am using a test along the lines of: #include inkey.ch #include hbgtinfo.ch FUNCTION MAIN() REQUEST HB_GT_XWC, HB_GT_CRS, HB_GT_TRM hb_gtInfo( HB_GTI_CLOSABLE, .F. ) hb_gtInfo( HB_GTI_WINTITLE, X Clipboard/PrimarySelection test ) hb_gtInfo( HB_GTI_SELECTCOPY, .T. ) hb_gtInfo( HB_GTI_RESIZABLE, .F. ) @ 1, 1 SAY Copy in something (key) InKey(0) @ 2, 1 SAY Clipboard data: alert( hb_gtInfo( HB_GTI_CLIPBOARDDATA ) ) @ 3, 1 SAY Copying in 'erglebergle' (key) hb_gtInfo( HB_GTI_CLIPBOARDDATA, erglebergle ) InKey(0) @ 4, 1 SAY Paste primary (key) InKey(0) @ 5, 1 SAY Paste clipboard (key) InKey(0) @ 6, 1 SAY In clipboard: alert( HB_GTINFO( HB_GTI_CLIPBOARDDATA ) ) @ 8, 1 SAY Exit (key) InKey(0) RETURN NIL (that is, you are supposed to do what it says by copying from and pasting into other clients when the test app says so) the symptom is that when there is already data in the primary when this app is started, the first inkey(0) is immediately satisfied (and then it shows the correct content for the primary selection). this doesn't happen absolutely always, but it does most of the time. if the primary is empty at app startup, then it never happens. another artifact is that upon exit (i start it from an xterm), it leaves some garbage someplace, which which causes my xterm to disappear if i press middle button. it's nothing that i could catch with careful use of xxd waiting for some binary junk, what's more, at one occasion this even killed my windowmaker (ok, it's not the stablest wm in the world, but for a couple of month, since outstandings have been fixed, i've been having much less problems with it than i used to). even worse, this doesn't seem to be tied to middle button events. i have had it by middle button, up arrow in shell, ^C in a shell line i decided not to execute... so the guess it that *something* is there that causes clients to exit unexpectedly. it is not even sure that the client that exits is the one that has the focus (i was just at this moment playing with other xterms when this one that runs my mua decided it's been long since i last saw my desktop background...) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] very strange compile error
On Thu, 17 Dec 2009, Przemysław Czerpak wrote: hi, g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W -O3 -o expropt1.o -c ../../../expropt1.c ../../../expropt1.c: In function `struct HB_EXPR_ * hb_compExprNewNegate(HB_EXPR_ *, _HB_COMMON *)': ../../../expropt1.c:1066: integer constant out of range 2. when g++ is used then in header files LLONG_MAX constant is defined without LL suffix, i.e.: #define LLONG_MAX 9223372036854775807 instead of: #define LLONG_MAX 9223372036854775807LL this is it, thanks. In both cases it's not Harbour problem and if the results are correct then you can ignore it. 2.95 is quite old version so I do not think it should be reported to GCC authors but if it's the only port of GNUC for SCO then you may want to do inform about it someone who manage it it's quite unlikely there's anyone left there :) i have manually corrected the above issue, now we got a bit further, but it's starting again with errors that i think ever should be there in the first place ( g++ -pthread -L../../../../../lib/unixware/gcc -o ../../../../../bin/unixware/gcc/hbpp hbpp.o -lhbnortl -lhbcommon -lm Undefined first referenced symbol in file std::exit(int) libhbnortl.a(nortl.o) UX:ld: ERROR: Symbol referencing errors. No output written to ../../../../../bin/unixware/gcc/hbpp wtf, no way this can be right) this is so creepy that i think i'll give up on g++ as a compiler for now. thanks for the hint, though, you teach me new stuff every day :) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13250] trunk/harbour
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote: hi, * harbour/include/hbinit.h + added new alternative form for initialization code activated by HB_INITSEG_STARTUP macro. This method uses asm() directive to store call to startup function in .init segment. you are The Man. big thanks! for me to work, i needed to mod it like this: - __asm__ ( .section .init\n\tcall HB_MACRO2STRING( func ) \n\t ); + asm ( .section .init\n\tcall HB_MACRO2STRING( func ) \n\t.section .text\n\t ); ie. a .section .text appended to the end (__asm__ vs asm is probably compiler-specific, i'll just if this to the compiler), in both occurances. shall i do this to section text too, or can it be added to your version without causing any ill effect on other platforms? -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13252] trunk/harbour
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote: * explicitly restore .text segment for compilers which do not make commit typo, it says .init at the end too :) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13253] trunk/harbour
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi
Revision: 13253
now something is broken again. i'm not sure what, as at one point i
had a working harbour (working at this stage i define as hbrun
starts), now for all of gcc/c, native/c, native/c++, when trying to
run hbrun, i get:
Error BASE/1003 Variable does not exist: S_AINCDIR
Called from _APPMAIN(90)
(gcc/c++ doesn't at the moment build because of some unrelated
platform-specific issue).
for all posterity i have the following changed wrt r13253 hbinit.h:
--- hbinit.h(revision 13253)
+++ hbinit.h(working copy)
@@ -112,7 +112,8 @@
#define HB_CALL_ON_STARTUP_END( func ) \
}
-#elif defined( HB_INITSEG_STARTUP )
+#elif ( defined( __USLC__ ) !defined( __cplusplus ) ) || \
+ defined( HB_INITSEG_STARTUP )
#define HB_INIT_SYMBOLS_BEGIN( func ) \
static HB_SYMB symbols_table[] = {
hbtest, for example, runs fine, so this probably has nothing to do
with this awesome work of yours in the startup area, but then i am at
a loss what's gone booboo again.
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13255] trunk/harbour
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi,
Revision: 13255
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13255view=rev
Author: druzus
Date: 2009-12-15 23:24:29 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-16 00:24 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/bin/hb-func.sh
* use -n2 as default harbour compiler parameter in hb* scripts
that didn't really help, and it's getting even more strange.
the build log clearly shows harbour still being called with -n1, i
checked the older ones, it was so all along the way as well.
the completely strange part is that if, using the very same options,
copy-pasted from the build log, i build a private copy of hbrun,
then it works.
so, the result of a make in the source tree gets me a
bin/$plat/$comp/hbrun which gives BASE/1003
the following gives a working hbrun:
unixware714:~/hb/harbour$ env | fgrep HB
unixware714:~/hb/harbour$ gmake ../log 21
unixware714:~/hb/harbour$ ./bin/unixware/gcc/hbrun
Error BASE/1003 Variable does not exist: S_AINCDIR
Called from _APPMAIN(90)
unixware714:~/hb/harbour$ ./bin/unixware/gcc/harbour utils/hbrun/hbrun.prg
-iinclude -n1 -q0 -w2 -es2 -kmo -i- -l
unixware714:~/hb/harbour$ gcc -DHB_OS_UNIXWARE -I. -Iinclude -D_SCO_DS
-Wall -W -O3 -o hbrun.o -c hbrun.c
unixware714:~/hb/harbour$ gcc -pthread -I. -Llib/unixware/gcc
-Iinclude -L/usr/X11R6/lib -ohbrun hbrun.o -lhbcplr -lhbpp
-lhbcommon -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage
-lgtcgi -lgtpca -lgtstd -lgtcrs -lgtxwc -lgttrm -lhbrdd
-lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbsix -lhbhsx -lhbusrrdd
-lhbuddall -lhbrtl -lhbvm -lhbmacro -lhbcplr -lhbpp -lhbcommon
-lhbpcre -lcurses -lX11 -lz -lsocket -lnsl -lresolv -lm
unixware714:~/hb/harbour$ ./hbrun -- runs fine
what gets me thinking is that the size difference between the two
files is relatively big:
-rwxr-xr-x1 ice other 3541060 Dec 16 00:54 ./hbrun
-rwxr-xr-x1 ice other 3541592 Dec 16 00:52
bin/unixware/gcc/hbrun
which they proportionally keep after being stripped:
-rwxr-xr-x1 ice other 3252400 Dec 16 01:05 ./hbrun
-rwxr-xr-x1 ice other 3252848 Dec 16 01:05 bin/unixware/gcc/hbrun
and even after a treat of `mcs -d': (this strips the .comment
sections, which the native binutils populate with the exact versions
of files, tools and stuff that were involved producing said elf
object):
-rwxr-xr-x1 ice other 3031452 Dec 16 01:05 ./hbrun
-rwxr-xr-x1 ice other 3031900 Dec 16 01:05 bin/unixware/gcc/hbrun
there is no real (to me..) difference between the generated c sources:
unixware714:~/hb/harbour$ /usr/local/bin/diff -u ./hbrun.c
./utils/hbrun/obj/unixware/gcc/hbrun.c
--- ./hbrun.c 2009-12-16 00:53:29.24007 +0100
+++ ./utils/hbrun/obj/unixware/gcc/hbrun.c 2009-12-16 00:52:07.19002
+0100
@@ -1,7 +1,7 @@
/*
* Harbour 2.0.0beta3 (Rev. 13256)
* GNU C 2.95 (32-bit)
- * Generated C source from utils/hbrun/hbrun.prg
+ * Generated C source from ../../../hbrun.prg
*/
#include hbvmpub.h
@@ -156,7 +156,7 @@
{ HB_GT_PCA, {HB_FS_PUBLIC}, {HB_FUNCNAME( HB_GT_PCA )}, NULL },
{ HB_GT_STD, {HB_FS_PUBLIC}, {HB_FUNCNAME( HB_GT_STD )}, NULL },
{ (_INITSTATICS3), {HB_FS_INITEXIT | HB_FS_LOCAL}, {hb_INITSTATICS},
NULL }
-HB_INIT_SYMBOLS_EX_END( hb_vm_SymbolInit_HBRUN, utils/hbrun/hbrun.prg, 0x0,
0x0002 )
+HB_INIT_SYMBOLS_EX_END( hb_vm_SymbolInit_HBRUN, ../../../hbrun.prg, 0x0,
0x0002 )
#if defined( HB_PRAGMA_STARTUP )
#pragma startup hb_vm_SymbolInit_HBRUN
yet, there is some strange (related?) difference between the c strings
in the binaries (hbrun.ok and hbrun.bad are the outputs of `strings' on
the working and the non-working binaries, respectively):
unixware714:~/hb/harbour$ /usr/local/bin/diff -u1 hbrun.ok hbrun.bad
--- hbrun.ok2009-12-16 01:13:37.70100 +0100
+++ hbrun.bad 2009-12-16 01:13:44.94011 +0100
@@ -8,2 +8,3 @@
__MVSETBASE
+S_NCOL
HB_HRBDO
@@ -35,2 +36,3 @@
OUTSTD
+S_NROW
ALLTRIM
@@ -66,2 +68,3 @@
PCOUNT
+S_AINCDIR
AADD
@@ -70,3 +73,4 @@
_APPMAIN
-utils/hbrun/hbrun.prg
+HBRUN
+hbrun.prg
HB_INC_INSTALL
@@ -83,2 +87,3 @@
dd
+z1S(
j'Harbour DOt Prompt Console / runner
... ok, so these suspiciously look like the static variables in
hbrun.prg (and are good account for the size difference)...
and i am lost again. if i am doing this, i have no idea how...
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
Re: [Harbour] SF.net SVN: harbour-project:[13255] trunk/harbour
On Wed, 16 Dec 2009, Tamas TEVESZ wrote: hi, that didn't really help, and it's getting even more strange. [...] nevermind. all of a sudden it started working. if i did this, i have no idea, what did i do. i'm going to stick a screwdriver through this thing and go become a shepherd in new zealand. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13255] trunk/harbour
On Wed, 16 Dec 2009, Viktor Szakáts wrote: I wonder why this didn't came up earlier, for one thing hbmk script is unrelated to default build process, and in default build process -n1 option is added by config/rules.mk. This is right for libs, but not right for bins. (default build process also uses hbmk2, but it's using -n1/-n2 correctly) So question is: Why is a problem now, and why wasn't it so far? i honestly have no freaking idea. i had one good build for at just about when przemek started adding initsegstartup, then everything went completely haywire for several hours (nothing that i could attribute to any change he made), and then suddenly it started working again. i *am* cleaning aggressively, to the extent of: cd `dirname $0`/harbour rm -rf `find . -type d -name obj` lib/unixware/ bin/unixware/ and i have no idea why it turned upside down, nor do i know what made it behave well again. i did not however do blind check builds on other platforms. it probably must have been a heisenbug or a hiccup in my setup (in fact there still is one quite strange phenomenon, but i'm still trying to hunt that down, before inevitably failing and crying for help:)... (correction is easy after that point) in fact the build procedure still runs -n1, and now all is fine. Brgds, Viktor On 2009 Dec 16, at 01:37, Tamas TEVESZ wrote: On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote: hi, Revision: 13255 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13255view=rev Author: druzus Date: 2009-12-15 23:24:29 + (Tue, 15 Dec 2009) Log Message: --- 2009-12-16 00:24 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/bin/hb-func.sh * use -n2 as default harbour compiler parameter in hb* scripts that didn't really help, and it's getting even more strange. the build log clearly shows harbour still being called with -n1, i checked the older ones, it was so all along the way as well. the completely strange part is that if, using the very same options, copy-pasted from the build log, i build a private copy of hbrun, then it works. so, the result of a make in the source tree gets me a bin/$plat/$comp/hbrun which gives BASE/1003 the following gives a working hbrun: unixware714:~/hb/harbour$ env | fgrep HB unixware714:~/hb/harbour$ gmake ../log 21 unixware714:~/hb/harbour$ ./bin/unixware/gcc/hbrun Error BASE/1003 Variable does not exist: S_AINCDIR Called from _APPMAIN(90) unixware714:~/hb/harbour$ ./bin/unixware/gcc/harbour utils/hbrun/hbrun.prg -iinclude -n1 -q0 -w2 -es2 -kmo -i- -l unixware714:~/hb/harbour$ gcc -DHB_OS_UNIXWARE -I. -Iinclude -D_SCO_DS -Wall -W -O3 -o hbrun.o -c hbrun.c unixware714:~/hb/harbour$ gcc -pthread -I. -Llib/unixware/gcc -Iinclude -L/usr/X11R6/lib -ohbrun hbrun.o -lhbcplr -lhbpp -lhbcommon -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtcrs -lgtxwc -lgttrm -lhbrdd -lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbsix -lhbhsx -lhbusrrdd -lhbuddall -lhbrtl -lhbvm -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lcurses -lX11 -lz -lsocket -lnsl -lresolv -lm unixware714:~/hb/harbour$ ./hbrun -- runs fine what gets me thinking is that the size difference between the two files is relatively big: -rwxr-xr-x1 ice other 3541060 Dec 16 00:54 ./hbrun -rwxr-xr-x1 ice other 3541592 Dec 16 00:52 bin/unixware/gcc/hbrun which they proportionally keep after being stripped: -rwxr-xr-x1 ice other 3252400 Dec 16 01:05 ./hbrun -rwxr-xr-x1 ice other 3252848 Dec 16 01:05 bin/unixware/gcc/hbrun and even after a treat of `mcs -d': (this strips the .comment sections, which the native binutils populate with the exact versions of files, tools and stuff that were involved producing said elf object): -rwxr-xr-x1 ice other 3031452 Dec 16 01:05 ./hbrun -rwxr-xr-x1 ice other 3031900 Dec 16 01:05 bin/unixware/gcc/hbrun there is no real (to me..) difference between the generated c sources: unixware714:~/hb/harbour$ /usr/local/bin/diff -u ./hbrun.c ./utils/hbrun/obj/unixware/gcc/hbrun.c --- ./hbrun.c 2009-12-16 00:53:29.24007 +0100 +++ ./utils/hbrun/obj/unixware/gcc/hbrun.c 2009-12-16 00:52:07.19002 +0100 @@ -1,7 +1,7 @@ /* * Harbour 2.0.0beta3 (Rev. 13256) * GNU C 2.95 (32-bit) - * Generated C source
[Harbour] g++2.95/g++3.3 bad build
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 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. full build logs of 2.95 are at http://dawn.dev.hu/~ice/tmp/g295.zip 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. thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors under ubuntu
On Tue, 15 Dec 2009, Viktor Szakáts wrote: hi, Try exchanging line 56 with line 58 in contrib/hbqt/detect.mk and report results. Even if this works I'd appreciate if someone could give ideas how to make moc tool detection reliable on the long run, while keeping it simple. Distros are apparently messing it up badly, but maybe someone can see the big picture here and there is logic in it. the current one looks ok to me. i think angel has his moc configuration screwed up. angel, what do you get (on a completely clean checkout) after you have had moc pointing to moc-qt4 by running `update-alternatives --config moc' (and obviously selecting moc-qt4)? if i'm right, then viktor, i don't think an explicit test for moc-qt4 is needed (unless the qt sdk itself has it so, which i do not know), but people need to learn their tools. the logic is that (since one can have qt3 and qt4 dev installed simultaneously), one gets to decide which one does one want by default. you trying to work around users picking the wrong one (or not picking the right one) is an uphill battle, and you probably have better things to do ;) Brgds, Viktor On 2009 Dec 15, at 00:11, Angel Pais wrote: Hello All If I'm doing nothing wrong I'm getting this errors under UBUNTU gcc -I. -I../../../../../include -Wall -W -O3 -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork -omoc_hbqt_events.o -c moc_hbqt_events.cpp moc_hbqt_events.cpp:15:34: error: private/qucomextra_p.h: No existe el fichero ó directorio moc_hbqt_events.cpp:17:2: error: #error This file was generated using the moc from 3.3.8b. It moc_hbqt_events.cpp:18:2: error: #error cannot be used with the include files from this version of Qt. moc_hbqt_events.cpp:19:2: error: #error (The moc has changed too much.) moc_hbqt_events.cpp:22: error: no ‘const char* Events::className() const’ member function declared in class ‘Events’ moc_hbqt_events.cpp:27: error: ‘QMetaObject* Events::metaObj’ is not a static member of ‘class Events’ moc_hbqt_events.cpp:28: error: ‘QMetaObjectCleanUp’ does not name a type moc_hbqt_events.cpp:31: error: redefinition of ‘static QString Events::tr(const char*, const char*)’ ../../../hbqt_events.h:68: error: ‘static QString Events::tr(const char*, const char*)’ previously defined here moc_hbqt_events.cpp:39: error: redefinition of ‘static QString Events::trUtf8(const char*, const char*)’ ../../../hbqt_events.h:68: error: ‘static QString Events::trUtf8(const char*, const char*)’ previously defined here moc_hbqt_events.cpp:50: error: no ‘QMetaObject* Events::staticMetaObject()’ member function declared in class ‘Events’ moc_hbqt_events.cpp:68: error: no ‘void* Events::qt_cast(const char*)’ member function declared in class ‘Events’ moc_hbqt_events.cpp:75: error: ‘QUObject’ has not been declared moc_hbqt_events.cpp:75: error: no ‘bool Events::qt_invoke(int, int*)’ member function declared in class ‘Events’ moc_hbqt_events.cpp:80: error: ‘QUObject’ has not been declared moc_hbqt_events.cpp:80: error: no ‘bool Events::qt_emit(int, int*)’ member function declared in class ‘Events’ moc_hbqt_events.cpp:86: error: no ‘bool Events::qt_property(int, int, QVariant*)’ member function declared in class ‘Events’ moc_hbqt_events.cpp:91: error: no ‘bool Events::qt_static_property(QObject*, int, int, QVariant*)’ member function declared in class ‘Events’ make[3]: *** [moc_hbqt_events.o] Error 1 make[2]: *** [descend] Error 2 make[1]: *** [hbqt] Error 2 make: *** [contrib] Error 2 HTH Angel ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors under ubuntu
On Tue, 15 Dec 2009, Viktor Szakáts wrote: hi, the logic is that (since one can have qt3 and qt4 dev installed simultaneously), one gets to decide which one does one want by default. you trying to work around users picking the wrong one (or not picking the right one) is an uphill battle, and you probably have better things to do ;) Makes perfect sense, and I'd be more than willing to delete check for moc-qt4 (which would need to be updated after each major QT release...), but this leads us back to the starting point: the reason I added moc-qt4 check was this messages: From: Bisz István istvan.b...@t-online.hu Date: 2009 November 19 17:30:41 CET To: 'Harbour Project Main Developer List.' harbour@harbour-project.org Subject: RE: [Harbour] SF.net SVN: harbour-project:[12938] trunk/harbour Reply-To: Harbour Project Main Developer List. harbour@harbour-project.org Thanks, finally I can locate it: /usr/bin/moc-q4 is the executable. I am in dialog with me, sorry... Thanks, finally I can locate it: /usr/bin/moc-qt4 is the executable. We should change moc to moc-qt4 for Fedora. well, i am not a fedora person, but a quick google session came up with this: http://www.linux-archive.org/fedora-packaging/114031-moc-moc-qt4.html a quick look at f12's qt spec shows that this is probably still the case, so in the end i don't really know. fedora people would most likely appreciate it keeping so, on the other hand i can't help but wonder when will they actually stop shipping tar, and start shipping only tar-1.22 instead... i've always thought you can't get any more retarded than debian, but oh well... -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] porting help needed again
hi, got this: g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W -O3 -o expropt1.o -c ../../../expropt1.c In file included from ../../../../../include/hbvmpub.h:56, from ../../../../../include/hbapi.h:61, from ../../../../../include/hbcompdf.h:57, from ../../../../../include/hbmacro.h:62, from ../../../expropt1.c:58: ../../../../../include/hbdefs.h:1624: multiple storage classes in declaration of `PHB_FUNC' ../../../../../include/hbdefs.h:1625: multiple storage classes in declaration of `HB_FUNC_PTR' ../../../expropt1.c: In function `struct HB_EXPR_ * hb_compExprNewNegate(HB_EXPR_ *, _HB_COMMON *)': ../../../expropt1.c:1066: integer constant out of range gmake[3]: *** [expropt1.o] Error 1 happens only with g++ (2.95), not with gcc or the native c/c++ compiler. now i know i've seen this before, but in a momentary lapse of sanity that's been going on for several days now i can't for the life of me recall or figure out where where to attack this. bring the cluesticks! -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] gcc2
hi, would someone with gcc2 handy get me the output of gcc -dM -E -xc /dev/null please? (whatever /dev/null is on your platform; running it on an empty file is good, too.) please indicate what platform you are on. i am not at the moment interested in any other gcc version, only v2. thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] enhance hbsocket.c portability
hi, these two are quite synonymous (so maybe extending the patch to include the reverse case could be useful later on as well). Index: src/rtl/hbsocket.c === --- src/rtl/hbsocket.c (revision 13223) +++ src/rtl/hbsocket.c (working copy) @@ -220,6 +220,10 @@ # define SHUT_RDWR 2 #endif +#if !defined( IPV6_JOIN_GROUP ) defined( IPV6_ADD_MEMBERSHIP ) +# define IPV6_JOIN_GROUP IPV6_ADD_MEMBERSHIP +#endif + #if defined( __WATCOMC__ ) defined( HB_OS_LINUX ) !defined( IP_ADD_MEMBERSHIP ) /* it's missed in OpenWatcom 1.8 Linux header files :-( */ # define IP_ADD_MEMBERSHIP 35 -- [-] mkdir /nonexistentIndex: src/rtl/hbsocket.c === --- src/rtl/hbsocket.c (revision 13223) +++ src/rtl/hbsocket.c (working copy) @@ -220,6 +220,10 @@ # define SHUT_RDWR 2 #endif +#if !defined( IPV6_JOIN_GROUP ) defined( IPV6_ADD_MEMBERSHIP ) +# define IPV6_JOIN_GROUP IPV6_ADD_MEMBERSHIP +#endif + #if defined( __WATCOMC__ ) defined( HB_OS_LINUX ) !defined( IP_ADD_MEMBERSHIP ) /* it's missed in OpenWatcom 1.8 Linux header files :-( */ # define IP_ADD_MEMBERSHIP 35 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] argmax again
hi, i have hit a case where the libharbour.so linking phase generates a command line of about 33k, while this system's limit is about 10k. i reckon this is the first unix we've hit this on, accordingly i can't really find anything to follow. i think that on other limited systems the linker can be fed from a file containing the objects to link, but there's nothing of the sorts i find here. cluestick, please? thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbver.c:iVerMinor and szSub
hi, could i please have the implicit short intness of iverpatch ( hb_snprintf( pszCompiler, COMPILER_BUF_SIZE, %s%s %hd.%hd.%hd, pszName, szSub, iVerMajor, iVerMinor, iVerPatch ); ) lifted, and szSub extended by a few octets? i'm massaging a compiler that encodes MM in the patch level, and the canonical version string rather needs a shoehorn fitting in 32 octets. thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbver.c:iVerMinor and szSub
(subject should have read iVerPatch of course) could i please have the implicit short intness of iverpatch ( hb_snprintf( pszCompiler, COMPILER_BUF_SIZE, %s%s %hd.%hd.%hd, pszName, szSub, iVerMajor, iVerMinor, iVerPatch ); ) lifted, and szSub extended by a few octets? i'm massaging a compiler that encodes MM in the patch level, and the canonical version string rather needs a shoehorn fitting in 32 octets. thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13174] trunk/harbour
On Wed, 9 Dec 2009, Tamas TEVESZ wrote: ! HB_USER_CFLAGS: -DHB_STATIC_STARTUP i am so shutting up right about now. i forgot this in from a previous experiment ;( sorry for the noise. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13154] trunk/harbour
On Mon, 7 Dec 2009, dru...@users.sourceforge.net wrote: hi, Revision: 13154 * harbour/src/rdd/dbfcdx/dbfcdx1.c * modified to use unique names for startup functions yup, much better now, all artifacts seem to have disappeared, thanks! -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbtpathy/tpunix question
On Sun, 6 Dec 2009, Viktor Szakáts wrote:
I'm leaving this to you as it obviously has no point for
me to update it while I don't understand a single bit about it.
I can restore original state but that won't help on the
original problem.
here's the deal in condensed form: CRTSCTS is system-dependendant.
most every system could have it, but some don't. right now, the only
one that doesn't have it is the watcom runtime on linux, but as we
know what CRTSCTS is on linux (by way of extracting it from libc), we
know how to make watcom define it to the correct value.
the modifications przemek proposed makes the code reflect this line of
thinking (so that probably noone will make the same mistake i made
thinking there's no point for extra guards), and if one ever
encounters another platform without CRTSCTS, he sees that
- he either needs to come up with a value for CRTSCTS by some means
(platform-specific tricks, experiments, crystal ball), or
- we'll completely skip the code path that depepnds on a known CRTSCTS
(and generate a warning to signal that there is something that you
should probably fix up for full user experience)
the specific cases przemek cited were just to show that the
actual value is system-dependant, not because they needed to be put in
the code, as those systems are fine enough to indicate the needed
values by themselves.
this seems to be what przemek is getting to. it's essentially the same
in effect that was in before, but is hopefully way more verbose in
telling why it's there.
Index: tpunix.c
===
--- tpunix.c(revision 13140)
+++ tpunix.c(working copy)
@@ -267,22 +267,18 @@
hb_retl( FALSE );
}
-#if ! defined( CRTSCTS )
- #if defined( HB_OS_LINUX ) ||
- defined( HB_OS_SUNOS )
- #define CRTSCTS0x8000
- #elif defined( HB_OS_BSD )
- #define CRTSCTS0x0001
- #elif defined( HB_OS_BEOS )
- #define CRTSCTS0x6000
- #elif defined( HB_OS_DARWIN )
- #define CRTSCTS0x0003
- #endif
+#if !defined( CRTSCTS )
+# if defined( HB_OS_LINUX ) defined( __WATCOMC__ ) __WATCOMC__ 1290
+# define CRTSCTS 0200
+# endif
#endif
HB_FUNC( __TP_CTRLCTS )
{
-#if defined( CRTSCTS )
+#if !defined( CRTSCTS )
+ int iTODO;
+ hb_retni( 0 );
+#else
struct termios options;
int port = hb_parnl( 1 );
int newvalue = hb_pcount() == 2 ? hb_parnl( 2 ) : -1;
@@ -301,9 +297,6 @@
rc = tcsetattr( port, TCSAFLUSH, options );
hb_retni( curvalue ? 1 : 0 );
-#else
- int iTODO;
- hb_retni( 0 );
#endif
}
as i see it, the essential difference is as follows:
#if !defined( CRTSCTS ) defined( __WATCOMC__ )
# define CRTSCTS 0200
#endif
what this tells is crtscts might not be defined on linux/watcom, so
here's what it should be.
#if !defined( CRTSCTS )
# if defined( HB_OS_LINUX ) defined( __WATCOMC__ ) __WATCOMC__ 1290
# define CRTSCTS 0200
# endif
#endif
what this tells is crtscts might not be defined. we know one such
case is this older versions of watcom on linux, where crtscts should
be this..
while the end result is quite the same, it makes whoever is reading
think in a different way, which is actually needed here, as przemek
helpfully explained.
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HB_STRICT_ANSI_C, does it work?
hi, i've been toying with a platform where (due to compiler, erhm, issues) my best bet for startup seems to be hb_strict_ansi_c, however it doesn't seen to work. i've checked setting this on linux/gcc, and it doesn't work either. even compilation doesn't succeed by throwing lots of multiply defined symbol and other suspicions (read, they aren't there in other cases) errors along the lines of: gcc -I. -I../../../../../../include -DHB_STRICT_ANSI_C -Wall -W -O3 -I/usr/include -ogtxwc.o -c ../../../gtxwc.c ../../../gtxwc.c:4306: warning: return type defaults to ‘int’ ../../../gtxwc.c: In function ‘_hb_startup_gt_Init_’: ../../../gtxwc.c:4308: warning: control reaches end of non-void function gcc -shared [...] -o ../../../../../lib/linux/gcc/libharbour-2.0.0.so [...] gtxwc.c:(.text+0x2f0): multiple definition of `_hb_startup_gt_Init_' ../../../../../src/rtl/gtcgi/obj/linux/gcc/gtcgi_dyn.o:gtcgi.c:(.text+0x230): first defined here collect2: ld returned 1 exit status these are present in gt drivers, also rdds and the code page stuff. if the linker is convinced (by judicious application of -z muldefs) to just do something, it's not very surprisingly doesn't work either: tinky:~/w/xhb/hbci/harbour-build$ ./bin/linux/gcc/hbrun Unrecoverable error 9998: Harbour terminal (GT) initialization failure hence the question, does HB_STRICT_ANSI_C work? how does it work? when does it work? thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13149] trunk/harbour
On Mon, 7 Dec 2009, vszak...@users.sourceforge.net wrote: hi, [libpng] * Updated to 1.2.41 (from 1.2.40) broke linux x win/watcom cpp ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: make 3.81 /bin/sh ! HB_INSTALL_PREFIX: /home/ice/w/xhb/hbci/inst/win/watcom/cpp ! HB_BUILD_DEBUG: yes ! HB_BUILD_OPTIM: no ! HB_BUILD_MODE: cpp ! HB_BUILD_EXTDEF: no ! HB_CONTRIBLIBS: no ! HB_HOST_PLAT: linux (x86_64) HB_SHELL: sh ! HB_PLATFORM: win (x86) ! HB_COMPILER: watcom ! HB_BIN_COMPILE not specified. Automatically set to: /usr/bin ! Component: 'zlib' found in /home/ice/w/xhb/hbci/harbour-build/external/zlib (local) ! Component: 'pcre' found in /home/ice/w/xhb/hbci/harbour-build/external/pcre (local) ! Component: 'openssl' not supported with watcom compiler ! Component: 'gpm' not supported on win platform ! Component: 'slang' not found ! Component: 'curses' not found ! Component: 'x11' not found ! Component: 'wattcp/watt-32' not supported on win platform ! REVISION: 13150 make[2]: Nothing to be done for `all'. make[1]: Nothing to be done for `all'. ! 'libhpdf' library skipped (platform or compiler not supported) wcc386 -zq -bt=nt -bm -w0 -3s -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -I/home/ice/w/xhb/hbci/harbour-build/external/zlib -fo=png.obj ../../../png.c wcc386 -zq -bt=nt -bm -w0 -3s -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -I/home/ice/w/xhb/hbci/harbour-build/external/zlib -fo=pngerror.obj ../../../pngerror.c wcc386 -zq -bt=nt -bm -w0 -3s -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -I/home/ice/w/xhb/hbci/harbour-build/external/zlib -fo=pnggccrd.obj ../../../pnggccrd.c wcc386 -zq -bt=nt -bm -w0 -3s -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -I/home/ice/w/xhb/hbci/harbour-build/external/zlib -fo=pngget.obj ../../../pngget.c wcc386 -zq -bt=nt -bm -w0 -3s -i. -i../../../../../include -d2 -DHB_TR_LEVEL_DEBUG -I/home/ice/w/xhb/hbci/harbour-build/external/zlib -fo=pngmem.obj ../../../pngmem.c ../../../pngmem.c(447): Error! E1057: Modifiers disagree with previous definition of 'png_calloc' ../../../pngmem.c(447): Note! I2002: 'png_calloc' defined in: ../../../png.h(3754) make[3]: *** [pngmem.obj] Error 1 make[2]: *** [descend] Error 2 make[1]: *** [libpng] Error 2 make: *** [external] Error 2 -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
On Sat, 5 Dec 2009, Viktor Szakáts wrote: continues about the mingw project. First they use .lzma extension instead of well-known .7z. Fine. Then they insist they are by far not the same. .lzma to .7z is what .gz is to .zip, on using .tar inside the .7z file, which is a solid archive anyway, so .tar doesn't give any size advantages. Then they hence the need for a container, which they chose to be tar (probably because 7z can't, or they thought it can't store attributes they needed) (it probably can). insist on using *nix links inside the .tar meant for the Windows platform which doesn't have support for such links. technically, it does, has had for quite some time. practically, if i had to pick between using these features of ntfs and the cheese greeter, i'd probably pick the cheese greeter. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbtpathy/tpunix question
hi,
contrib/hbtpathy/tpunix.c:
270 HB_FUNC( __TP_CTRLCTS )
271 {
272 #if !defined( CRTSCTS ) defined( __WATCOMC__ )
273 # define CRTSCTS 0200
274 #endif
is there a reason for the defined( __WATCOMC__ ) part? i've just
found another platform where CRTSCTS isn't defined, and am wondering
whether anyone has anything against, or a better idea instead of, just
dropping the watcom constraint from this conditional.
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
On Sat, 5 Dec 2009, Viktor Szakáts wrote: hence the need for a container, which they chose to be tar (probably because 7z can't, or they thought it can't store attributes they needed) (it probably can). It's still an insane idea. Even .tar.gz is insane on Windows. i have never for one split second argued against this very true statement :) practically, if i had to pick between using these features of ntfs and the cheese greeter, i'd probably pick the cheese greeter. Hm, what is a cheese greeter? :o that's what cheese grater becomes when i'm simultaneously trying to type cheese grater and saying gdmgreeter out loud :) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbtpathy/tpunix question
On Sat, 5 Dec 2009, Viktor Szakáts wrote:
270 HB_FUNC( __TP_CTRLCTS )
271 {
272 #if !defined( CRTSCTS ) defined( __WATCOMC__ )
273 # define CRTSCTS 0200
274 #endif
is there a reason for the defined( __WATCOMC__ ) part? i've just
found another platform where CRTSCTS isn't defined, and am wondering
whether anyone has anything against, or a better idea instead of, just
dropping the watcom constraint from this conditional.
Probably can be dropped. More could be told by checking
file history, maybe you can spot who added it and with
what comment.
it says:
2008-07-17 03:36 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbtpathy/tplinux.c
* workaround for missing CRTCTS declaration in OpenWatcom
so i guess no harm dropping it.
thanks,
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13083] trunk/harbour
On Tue, 1 Dec 2009, vszak...@users.sourceforge.net wrote: Log Message: --- 2009-12-01 12:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * config/global.mk % De-xmastree-d two more if/else structures. you SO are my hero. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbide
On Mon, 30 Nov 2009, Davor Siklic wrote: s...@siki:~/clipp/harbour/contrib/hbide$ hbmk2 hbide hbmk2 hbide.hbp -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12970] trunk/harbour
On Thu, 26 Nov 2009, Przemysław Czerpak wrote:
hi,
I've just committed it:
2009-11-26 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
a typo seems to have snuck in.
Index: src/vm/hvm.c
===
--- src/vm/hvm.c(revision 13028)
+++ src/vm/hvm.c(working copy)
@@ -11401,7 +11401,7 @@
void hb_vmUpdateAllocator( PHB_ALLOCUPDT_FUNC pFunc, int iCount )
{
- HB_TRACE(HB_TR_DEBUG, (hb_vmUpdateAllocator(%p, %d), pFunc, int iCount));
+ HB_TRACE(HB_TR_DEBUG, (hb_vmUpdateAllocator(%p, %d), pFunc, iCount));
#if defined( HB_MT_VM )
if( s_vmStackLst )
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Przemysław Czerpak wrote: that is exactly what's happening, and according to llvm bugzilla, this is what should be happening, see: http://www.mail-archive.com/llvmb...@cs.uiuc.edu/msg03238.html Please note that we are calling llvm-gcc to link final application and it does not work. I haven't check if it does not call llvm-ld but native ld or llvm-ld does not work correctly. It doesn't matter for us. Important is only that calling llvm-gcc to create binaries does not work with libraries created by llvm-ar what is a problem which should be resolved by packager or llvm authors. It's not out job to add workarounds for such things into core harbour code. so it may be that the solution is not HB_CCPREFIX after all, but a separate llvmgcc target, which, for starters, only sets HB_CMP. I still to think that it's good idea to encode workarounds for problems with other packages into harbour core code. IMHO much simpler temporary solution is: ln -sf /usr/bin/ar /usr/bin/llvm/ar from root account until someone will have not create llvm-gcc packages with llvm-gcc which can work with llvm-ar correctly. they work together correctly, if they are configured to work together correctly. my first stab, they were not. i'm much further now, and almost have a complete compilation+link cycle without workarounds like above (as i slowly start to understand how llvm + frontends work). it seems that the supposed improvements using llvm start pouring when it's also used for linking, see for example: http://www.nntp.perl.org/group/perl.perl5.porters/2008/06/msg137461.html this could be added as a next step, once an llvmgcc target is in there. It will not give any real improvement to Harbour HVM because we already enabled inter procedural optimization in whole HVM code by introducing hvmall.c so it works for compiler which do not have link time IPO. Few months ago I tested using ICC that it gives in practice the same improvement and introducing link time IPO does give farther speed optimizations but strongly increase the size of final binaries. So if LLVM/GCC does not disable some compile time IPO which exist in GCC then at current state there is not chance that using LLVM or CLANG we will have faster final code because we do not leave any time critical code which can be improved yet by link time IPO. i wholeheartedly believe you, but i still do not see this as a futile excercise. if nothing else, *i* will learn something new. HB_CCPREFIX seems absolutely not the way to go. Can you explain the above. I do not understand it. i do not really understand what is it you do not understand. HB_CCPREFIX is just that, prepending some prefix to the compiler and binutils and stuff names. in this llvmgcc case, modifying several compiler options is also needed, so setting only prefix is not enough. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] llvm ident fixup
On Sun, 22 Nov 2009, Viktor Szakáts wrote:
hi,
I'll commit something pretty soon, pls
take a look at it.
it gives the expected results with llvm/g{cc,++}, thanks.
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Sun, 22 Nov 2009, Viktor Szakáts wrote:
could you also add this (llvm-gcc) target to the mix? for all intents
and purposes, it is the very same as the gcc target, except compilers
being llvm-gcc and llvm-g++ instead of gcc and g++, respectively.
Can you try if it works by setting HB_CCPREFIX=llvm-
and using gcc target? If this seems ok, I may add it,
no, it doesn't:
HB_BUILD_DEBUG=yes
HB_CONTRIBLIBS=no
HB_COMMERCE=yes
HB_INSTALL_PREFIX=/home/ice/w/xhb/hbci/inst/linux/gcc/c
HB_COMPILER=gcc
HB_BUILD_MODE=c
HB_BUILD_OPTIM=no
HB_PLATFORM=linux
HB_CCPREFIX=llvm-
===
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh
! HB_INSTALL_PREFIX: /home/ice/w/xhb/hbci/inst/linux/gcc/c
! HB_BUILD_DEBUG: yes
! HB_BUILD_OPTIM: no
! HB_BUILD_MODE: c
! HB_CONTRIBLIBS: no
! HB_HOST_PLAT: linux (x86_64) HB_SHELL: sh
! HB_PLATFORM: linux (x86_64)
! HB_COMPILER: gcc
! Component: 'zlib' found in /usr/include
! Component: 'pcre' found in /usr/include
! Component: 'openssl' found in /usr/include
! Component: 'gpm' explicitly disabled
! Component: 'slang' explicitly disabled
! Component: 'curses' found in /usr/include
! Component: 'x11' found in /usr/include
! Component: 'wattcp/watt-32' not supported on linux platform
! REVISION: 12974
make[2]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
llvm-gcc -I. -I../../../../../include -g -DHB_TR_LEVEL_DEBUG -I/usr/include
-I/usr/include -o_hbhbpdf.o -c ../../../_hbhbpdf.c
[...]
llvm-gcc -I. -I../../../../../include -Wall -W -g -DHB_TR_LEVEL_DEBUG
-ostrwild_dyn.o -DHB_DYNLIB -fpic -c ../../../strwild.c
( llvm-ar rcs ../../../../../lib/linux/gcc/libhbcommon.a expropt1.o
expropt2.o hbffind.o hbfopen.o hbfsapi.o hbgete.o hbwince.o hbhash.o hbprintf.o
hbstr.o hbdate.o hbmem.o hbtrace.o hbver.o hbverdsp.o hbarch.o reserved.o
strwild.o ) || ( rm -f ../../../../../lib/linux/gcc/libhbcommon.a false )
llvm-gcc -I. -I../../../../../include -Wall -W -g -DHB_TR_LEVEL_DEBUG
-onortl.o -c ../../../nortl.c
( llvm-ar rcs ../../../../../lib/linux/gcc/libhbnortl.a nortl.o ) || ( rm -f
../../../../../lib/linux/gcc/libhbnortl.a false )
llvm-gcc -I. -I../../../../../include -Wall -W -g -DHB_TR_LEVEL_DEBUG
-ohbpp.o -c ../../../hbpp.c
llvm-gcc -I. -I../../../../../include -Wall -W -g -DHB_TR_LEVEL_DEBUG
-ohbpp_dyn.o -DHB_DYNLIB -fpic -c ../../../hbpp.c
llvm-gcc -Wall -W -g -L../../../../../lib/linux/gcc
-o../../../../../bin/linux/gcc/hbpp hbpp.o -lhbnortl -lhbcommon -lm
../../../../../lib/linux/gcc/libhbnortl.a: could not read symbols: Archive has
no index; run ranlib to add one
collect2: ld returned 1 exit status
make[3]: *** [hbpp] Error 1
rm hbpp.o
make[2]: *** [descend] Error 2
make[1]: *** [pp] Error 2
make: *** [src] Error 2
but using this:
--- gcc.mk 2009-11-22 14:00:24.0 +0100
+++ llvm-gcc.mk 2009-11-22 14:03:30.0 +0100
@@ -3,9 +3,9 @@
#
ifeq ($(HB_BUILD_MODE),cpp)
- HB_CMP := g++
+ HB_CMP := llvm-g++
else
- HB_CMP := gcc
+ HB_CMP := llvm-gcc
endif
OBJ_EXT := .o
it does (HB_COMPILER=llvm-gcc). i have no idea what the essential
difference is, but this way it does, HB_CCPREFIX way it doesn't. i've
also modified postinst.sh like
Index: postinst.sh
===
--- postinst.sh (revision 12974)
+++ postinst.sh (working copy)
@@ -49,7 +49,8 @@
[ $HB_COMPILER = cygwin ] || \
[ $HB_COMPILER = djgpp ] || \
[ $HB_COMPILER = icc ] || \
- [ $HB_COMPILER = sunpro ]
+ [ $HB_COMPILER = sunpro ] || \
+ [ $HB_COMPILER = llvm-gcc ]
then
if [ -n ${HB_TOOLS_PREF} ]; then
hb_mkdyn=${HB_INST_PKGPREF}${HB_BIN_INSTALL}/${HB_TOOLS_PREF}-mkdyn
this, and the installed tree seems mostly ok (what not ok is the
dynlib link generation, which is probably due to hb-mkdyn.sh also in
need of some massaging).
full build logs of both cases are available if needed (my build tests
only do hb core, ie. no contribs or anything).
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Sun, 22 Nov 2009, Przemysław Czerpak wrote: hi, HB_COMPILER=gcc HB_BUILD_OPTIM=no Why do you disable optimization? i don't know, i forgot already. the original intent was probably that probably noone else builds with optimizations disabled, so at least my tests should have a case for it. You have quite precise error message here. I've just checked that also in Suse11.2 llvm-ranlib does not create index which can be recognized by llvm-gcc. It's probably bug which should be reported to LLVM developers. As workaround I used ranlib instead of llvm-ranlib to create indexes and created full harbour build using HB_CCPREFIX=llvm- without any problems. that is exactly what's happening, and according to llvm bugzilla, this is what should be happening, see: http://www.mail-archive.com/llvmb...@cs.uiuc.edu/msg03238.html The difference is that such version used 'ar' instead of 'llvm-ar' which created working library indexes. Probably as dirty hack you can try to replace 'llvm-ar' with link to 'ar' and HB_CCPREFIX will work for you without any problems. so it may be that the solution is not HB_CCPREFIX after all, but a separate llvmgcc target, which, for starters, only sets HB_CMP. it seems that the supposed improvements using llvm start pouring when it's also used for linking, see for example: http://www.nntp.perl.org/group/perl.perl5.porters/2008/06/msg137461.html this could be added as a next step, once an llvmgcc target is in there. HB_CCPREFIX seems absolutely not the way to go. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
separate llvmgcc target, which, for starters, only sets HB_CMP. i'm fighting with the attached llvmgcc target definition, but i got stuck, and can't ffigure out where do cflags leak into ldflags. just try building it, you'll see. cluebat, please? -- [-] mkdir /nonexistent# # $Id: gcc.mk 12895 2009-11-16 08:52:59Z vszakats $ # ifeq ($(HB_BUILD_MODE),cpp) HB_CMP := llvm-g++ else HB_CMP := llvm-gcc endif OBJ_EXT := .o LIB_PREF := lib LIB_EXT := .a HB_DYN_COPT := -DHB_DYNLIB -fpic CC := $(HB_CCACHE) $(HB_CCPREFIX)$(HB_CMP)$(HB_CCPOSTFIX) CC_IN := -c CC_OUT := -o CPPFLAGS := -I. -I$(HB_INC_COMPILE) CFLAGS := -emit-llvm LDFLAGS := -native ifneq ($(HB_BUILD_WARN),no) CFLAGS += -Wall -W endif ifneq ($(HB_BUILD_OPTIM),no) CFLAGS += -O3 endif ifeq ($(HB_BUILD_DEBUG),yes) CFLAGS += -g endif ifneq ($(filter $(HB_BUILD_STRIP),all lib),) ARSTRIP = strip -S $(LIB_DIR)/$@ endif ifneq ($(filter $(HB_BUILD_STRIP),all bin),) LDSTRIP := -s DYSTRIP := -s endif # LD := $(HB_CCACHE) $(HB_CCPREFIX)$(HB_CMP)$(HB_CCPOSTFIX) LD := llvm-ld LD_OUT := -o$(subst x,x, ) LIBPATHS := $(foreach dir,$(LIB_DIR) $(SYSLIBPATHS),-L$(dir)) LDLIBS := $(foreach lib,$(HB_USER_LIBS) $(LIBS) $(SYSLIBS),-l$(lib)) LDFLAGS += $(LIBPATHS) AR := llvm-ar ARFLAGS := AR_RULE = ( $(AR) $(ARFLAGS) $(HB_USER_AFLAGS) rcs $(LIB_DIR)/$@ $(^F) $(ARSTRIP) ) || ( $(RM) $(LIB_DIR)/$@ false ) DY := $(CC) DFLAGS := -shared $(LIBPATHS) DY_OUT := -o$(subst x,x, ) DLIBS := $(foreach lib,$(HB_USER_LIBS) $(SYSLIBS),-l$(lib)) DY_RULE = $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ $^ $(DLIBS) $(DYSTRIP) $(LN) $(@F) $(DYN_FILE2) include $(TOP)$(ROOT)config/rules.mk ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12972] trunk/harbour
On Mon, 23 Nov 2009, Viktor Szakáts wrote: i'm fighting with the attached llvmgcc target definition, but i got stuck, and can't ffigure out where do cflags leak into ldflags. just try building it, you'll see. cluebat, please? For some reason CPPFLAGS is passed to linker (while CFLAGS isn't). This is so since the beginning, and no one has touched this remaining strangeness yet. it's actually CFLAGS, and is in rules.mk:66 is there any ill effect were it to be removed? i'm in a sort of a hurry now, but without this, at least linux/gcc, linux/g++, linux/sunpro and linux x os2/watcom c++ is still ok, whereas llvmgcc definitely gets further on (and now blows up in what at cursory eyeballing seems to be hb-mkdyn, which is understandable). -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] llvm ident fixup
viktor, i believe the following is better at identifying the actual llvm frontend used: tinky:~/w/xhb/hbci/harbour-build$ ../inst/linux/llvm/c/bin/harbour -build 21 | fgrep Compiler Compiler: LLVM/GNU C 4.2.1 (64-bit) tinky:~/w/xhb/hbci/harbour-build$ ../inst/linux/llvm/cpp/bin/harbour -build 21 | fgrep Compiler Compiler: LLVM/GNU C++ 4.2.1 (64-bit) without this, llvm/gcc gets identified as gcc. i don't have clang, but if that doesn't break for you, could you please apply this? thanks, Index: src/common/hbver.c === --- src/common/hbver.c (revision 12965) +++ src/common/hbver.c (working copy) @@ -623,11 +623,11 @@ pszName = EMX/RSXNT/Win32 GNU C; #elif defined( __EMX__ ) pszName = EMX GNU C; - #elif defined( __clang__ ) - #if defined( __llvm__ ) - pszName = Clang/LLVM C; + #elif defined( __llvm__ ) + #if defined( __clang__ ) + pszName = LLVM/Clang C; #else - pszName = Clang/GNU C; + pszName = LLVM/GNU C; #endif #else pszName = GNU C; -- [-] mkdir /nonexistentIndex: src/common/hbver.c === --- src/common/hbver.c (revision 12965) +++ src/common/hbver.c (working copy) @@ -623,11 +623,11 @@ pszName = EMX/RSXNT/Win32 GNU C; #elif defined( __EMX__ ) pszName = EMX GNU C; - #elif defined( __clang__ ) - #if defined( __llvm__ ) - pszName = Clang/LLVM C; + #elif defined( __llvm__ ) + #if defined( __clang__ ) + pszName = LLVM/Clang C; #else - pszName = Clang/GNU C; + pszName = LLVM/GNU C; #endif #else pszName = GNU C; ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] SF.net SVN: harbour-project:[12943] trunk/harbour
On Fri, 20 Nov 2009, Bisz István wrote: ../../../dlmalloc.c: In function 'void* dlmalloc(size_t)': ../../../dlmalloc.c:4107: warning: dereferencing pointer 'b' does break strict-aliasing rules there is an updated dlmalloc available from ftp://gee.cs.oswego.edu/pub/misc/ (2.8.4 as opposed to the in-tree 2.8.3, with a good 3.5yrs between them). my quick build tests show that neither watcom nor mingw (4.2.1 here) like it as-is, but to my untrained eye they don't look too difficult (from a cursory look it looks like they have something to do with mmap, to which end the in-tree version has some local changes). maybe przemek would want to take a peek whether updating to the newer upstream is of any benefit to hvm. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12818] trunk/harbour
On Tue, 3 Nov 2009, dru...@users.sourceforge.net wrote: Revision: 12818 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12818view=rev Author: druzus Date: 2009-11-03 12:37:01 + (Tue, 03 Nov 2009) Log Message: --- 2009-11-03 13:36 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/common/hbstr.c ! fixed typo in HB_TRACE message - problem reported by Alex * harbour/src/rtl/cdpapi.c ! fixed casting for C++ builds - problem reported by Marcos suncc is (still?) broken: sunCC -I. -I../../../../../include -erroff=%none -g -DHB_TR_LEVEL_DEBUG -o expropt1.o -c ../../../expropt1.c /usr/include/stdio.h, line 480: Error: ( expected instead of __attribute__. /usr/include/stdio.h, line 480: Error: ( expected instead of __attribute__. /usr/include/stdio.h, line 480: Error: ) expected instead of __attribute__. /usr/include/stdio.h, line 480: Error: ) expected instead of __attribute__. /usr/include/stdio.h, line 483: Error: ( expected instead of __attribute__. /usr/include/stdio.h, line 483: Error: ( expected instead of __attribute__. /usr/include/stdio.h, line 483: Error: ) expected instead of __attribute__. /usr/include/stdio.h, line 483: Error: ) expected instead of __attribute__. /usr/include/stdio.h, line 488: Error: ( expected instead of __attribute__. /usr/include/stdio.h, line 488: Error: ( expected instead of __attribute__. /usr/include/stdio.h, line 488: Error: ) expected instead of __attribute__. /usr/include/stdio.h, line 488: Error: ) expected instead of __attribute__. 12 Error(s) detected. make[3]: *** [expropt1.o] Error 12 make[2]: *** [descend] Error 2 make[1]: *** [common] Error 2 make: *** [src] Error 2 sunc is ok, though. -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Random links
On Thu, 29 Oct 2009, Viktor Szakáts wrote: BTW, does someone know if it's possible to run dosemu under amd64 Ubuntu? I'm tempted to move to 64-bit, but I'd cut myself out of DOS even more if it breaks dosemu. why not virtualbox? i'm quite sure even the opensource edition can run dos quite fine. i think i even have one setup up complete with networking n stuff, if you want (and i find it), i could send you that (it's basically a freedos + mslanman + i-forgot-what-tcpip, runs some custom app my mom has had for decades, which i'll rip out of course :). (rip out the app, not my mom.) -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bug: GTXWC and HB_GTI_WINTITLE
On Wed, 28 Oct 2009, Przemysław Czerpak wrote:
hb_gtInfo( HB_GTI_WINTITLE, string with accented chars )
doesn't seem to respect app CP (like now f.e. GTWVT does)
with GTXWC, accented chars don't appear correctly in title
bar.
I tried to fix it by converting to UTF8 in gtxwc.c, but I
may be missing something as it's still not right.
this is a shot in the dark, but anyway.
try adding
XChangeProperty( wnd-dpy, wnd-window,
XInternAtom( wnd-dpy, _NET_WM_NAME, False ),
XInternAtom( wnd-dpy, UTF8_STRING, False ),
8, PropModeReplace, wnd-szTitle, strlen( wnd-szTitle ));
right after calling XStoreName() in gtxwc.c (line 2965).
It will work and in such case it should be enough to replace
XStoreName() with above XChangeProperty().
But I'm interesting why you used _NET_WM_NAME property instead
of WM_NAME used by XStoreName().
net_wm_hints is supposed to be a newer standard than wm_hints (and
it's probably there for a reason). now, i don't know too much about x
programming, but i suppose that everything alive now speak net_wm, so
it just seemed natural.
Anyhow for final version I suggest to use XSetWMName() instead
of manually update properties:
according to the good old man, xsetwmname() sets wm_name, thus my
manual way of setting net_wm_name instead.
but whichever you see fit, i guess. if wm_name works too, without side
effects, then so be it.
if( wnd-fDspTitle )
{
wnd-fDspTitle = FALSE;
if( wnd-szTitle )
{
ULONG ulLen = hb_cdpStringInUTF8Length( wnd-hostCDP, TRUE,
wnd-szTitle, strlen( wnd-szTitle ) );
char * pBuffer = ( char * ) hb_xgrab( ulLen + 1 );
XTextProperty text;
hb_cdpStrnToUTF8( wnd-hostCDP, TRUE, wnd-szTitle, strlen(
wnd-szTitle ), pBuffer );
text.value = ( unsigned char * ) pBuffer;
text.encoding = s_atomUTF8String;
text.format = 8;
text.nitems = strlen( pBuffer );
XSetWMName( wnd-dpy, wnd-window, text );
hb_xfree( pBuffer );
}
else
XStoreName( wnd-dpy, wnd-window, );
}
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
--
[-]
mkdir /nonexistent
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bug: GTXWC and HB_GTI_WINTITLE
On Wed, 28 Oct 2009, Viktor Szakáts wrote: hb_gtInfo( HB_GTI_WINTITLE, string with accented chars ) doesn't seem to respect app CP (like now f.e. GTWVT does) with GTXWC, accented chars don't appear correctly in title bar. I tried to fix it by converting to UTF8 in gtxwc.c, but I may be missing something as it's still not right. this is a shot in the dark, but anyway. try adding XChangeProperty( wnd-dpy, wnd-window, XInternAtom( wnd-dpy, _NET_WM_NAME, False ), XInternAtom( wnd-dpy, UTF8_STRING, False ), 8, PropModeReplace, wnd-szTitle, strlen( wnd-szTitle )); right after calling XStoreName() in gtxwc.c (line 2965). it could be that it is needed after line 3358, but i couldn't quickly figure out what that block really is for (adding this there as well probably won't hurt anyway). -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] silence gnu find in postinst.sh
(doesn't hurt other finds)
Index: bin/postinst.sh
===
--- bin/postinst.sh (revision 12576)
+++ bin/postinst.sh (working copy)
@@ -46,7 +46,7 @@
fi
if [ $HB_PLATFORM != hpux ]; then
# Keep the size of the libraries to a minimim, but don't try to strip
symlinks.
- ${HB_CCPREFIX}strip -S `find $HB_LIB_INSTALL -type f -maxdepth 1`
+ ${HB_CCPREFIX}strip -S `find $HB_LIB_INSTALL -maxdepth 1 -type f`
fi
chmod 644 $HB_INC_INSTALL/*
--
[-]
mkdir /nonexistentIndex: bin/postinst.sh
===
--- bin/postinst.sh (revision 12576)
+++ bin/postinst.sh (working copy)
@@ -46,7 +46,7 @@
fi
if [ $HB_PLATFORM != hpux ]; then
# Keep the size of the libraries to a minimim, but don't try to strip
symlinks.
- ${HB_CCPREFIX}strip -S `find $HB_LIB_INSTALL -type f -maxdepth 1`
+ ${HB_CCPREFIX}strip -S `find $HB_LIB_INSTALL -maxdepth 1 -type f`
fi
chmod 644 $HB_INC_INSTALL/*
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] haiku fallout
hi, now with libharbour*.so installed in /boot/common/lib/harbour/, things don't find it. -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2 question: HB_GT_LIB=os2pm
On Fri, 18 Sep 2009, Viktor Szakáts wrote: hi, We have an option to set HB_GT_LIB to 'os2pm'. I'd like to ask OS/2 users what is the use of this, and do we still need it? (entirely uneducated guess) pm stands for presentation manager, which is the os/2 gui. i suspect this must have been a gt using pm :), all fingers point to contrib/hbgf and/or examples/hbgf, which appears to have been removed completely. -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku network stuff
On Fri, 18 Sep 2009, Przemyslaw Czerpak wrote: hi, Index: source/rtl/hbsocket.c === --- source/rtl/hbsocket.c (revision 12533) +++ source/rtl/hbsocket.c (working copy) @@ -58,6 +58,10 @@ # endif #endif +#if defined( HB_OS_BEOS ) +# define HB_SOCKET_TRANSLATE_TYPE +#endif + I think it's typo. I've just check in header ifles and only protocol fmailies/domain should be translated so above define should be: #define HB_SOCKET_TRANSLATE_DOMAIN you are right. i just checked, and it appears that translate_domain alone is enough. i saw you committed both, so the following should be applied to the current tree: Index: source/rtl/hbsocket.c === --- source/rtl/hbsocket.c (revision 12540) +++ source/rtl/hbsocket.c (working copy) @@ -126,7 +126,6 @@ # endif # if defined( HB_OS_BEOS ) # define HB_SOCKET_TRANSLATE_DOMAIN -# define HB_SOCKET_TRANSLATE_TYPE # endif # if defined( HB_OS_LINUX ) # define HB_HAS_SELECT_TIMER btw, did you find an alternative terminal, or could you make the build-in terminal work like a proper xterm? or some gt setting maybe? i'm having all kinds of character set problems, which disappear when i ssh in from my regular xterm -- but on the other hand, either sshd or the network hangs every now and then. of your environment is stable, or at least stable-ish, any info would be appreciated :) -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku network stuff
On Fri, 18 Sep 2009, Tamas TEVESZ wrote: the firtst hunk is apparently needed -- with that, netiotest actually starts and runs and seems to be doing its stuff fine. note, i'm deliberately not mentioning an exit of any sorts -- it doesn't, instead it eats up all memory and hangs, but that's for another day, it's netio_serverstop() that goes haywire. -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_sendmail issues under linux
On Thu, 17 Sep 2009, Lorenzo Fiorini wrote: In contrib/hbtip/sendmail.prg these lines: IF !( Right( cBody, 2 ) == hb_osNewLine() ) cBody += hb_osNewLine() ENDIF should be: IF !( Right( cBody, 2 ) == Chr( 13 ) + Chr( 10 ) ) cBody += Chr( 13 ) + Chr( 10 ) ENDIF but this is stlill wrong. code says: cBody - Optional. The body message of the email as text, or the filename of the HTML message to send. so, after that, you have to append crlf.crlf _no matter what is in cbody_ already. i think (from a quick skim of the code) that the correct solution would be deleting these three altogether, and the smtp client seems to already add this in it's commit(), which should be enough (and along these lines, appending anything to cbody is wrong). can you dump out a complete conversation, and get it to me? preferably protect it with something so that whitespaces and stuff are not mangled, base64, for example). the standard requires Cr+Lf and servers like QMail reject messages with ONLY Lf reporting: 451 See http://pobox.com/~djb/docs/smtplf.html while others like Postfix accept them but report: 354 End data with CRLF.CRLF Using Chr( 13 ) + Chr( 10 ) seems to fix the send with QMail but Postfix still reports 354 ... Any comments is welcome. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_sendmail issues under linux
On Thu, 17 Sep 2009, Viktor Szakáts wrote: i think (from a quick skim of the code) that the correct solution would be deleting these three altogether, and the smtp client seems to already add this in it's commit(), which should be enough (and along these lines, appending anything to cbody is wrong). I've tried to remove them but then a msg with an attachment is wrong. The client shows everything as text. Just a guess, but that appears to be some bugs in the attachment logic. It's strange that body needs to be hacked to make attachment work. Pbly attachment should add any linefeeds required. in hbtip/mail.prg:SetBody() there is: 151 METHOD SetBody( cBody ) CLASS TipMail 152IF ::oEncoder != NIL 153 ::cBody := ::oEncoder:Encode( cBody ) 154 ::lBodyEncoded := .T. //GD needed to prevent an extra crlf from being appended 155ELSE 156 ::cBody := cBody 157ENDIF 158::hHeaders[ Content-Length ] := hb_ntos( Len( cBody ) ) 159RETURN .T. maybe this has something to do with it? -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] netiosrv.c range check
hi przemek,
netiosrv.c reads:
440 if( connsd != HB_NO_SOCKET )
441 {
442 BOOL fOK = FALSE;
443 BYTE msgbuf[ 64 ];
444
445 conn = s_consrvNew( connsd, lsd-rootPath );
446
447 if( s_srvRecvAll( conn, msgbuf, NETIO_MSGLEN ) == NETIO_MSGLEN
it feels better to, instead of the magic 64, to either use some
formula that includes NETIO_MSGLEN (say 2 * NETIO_MSGLEN + 16, if
there is such a formula, or just some * NETIO_MSGLEN), or after the
declaration, assert() that msgbuf needs to be this-and-this in size in
relation to NETIO_MSGLEN.
my reason for that is that 64 is a magic constant, far in context
from where and how it's being used, and using netio_msglen in there
gives it some context, and is easier to figure out what it is for, and
what the constraints for it's size are.
--
[-]
mkdir /nonexistent
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
