On Mon, 07 Dec 2009, Tamas TEVESZ wrote: 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. The startup code covered by HB_STRICT_ANSI_C macro is not working code but rather type of code for dummy compilation when non of existing versions of statup initialization do not work. It means that you cannot create working binaries using it. But you can use it to create some alternative initialization method which will be added later as new startup form for some new platforms or C compilers. > 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 This we can easy pacify (I'll commit it in a while) but of course it does not mean that it will work in final binaries. Harbour needs some method to activate initialization code for each linked .prg module and many of core code subsystems which are linked optionally. > 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. It also can be pacified by declaring the dummy initialization function as static. Anyhow I can imagine startup code which may need public initialization functions so in some cases it may be good to keep names of core startup functions unique. If you plan to write such startup code then I can try to update Harbour core code. I.e. you can try to use some unique function name prefix for all functions which should be executed at application startup, then you can write some linker wrapper and collect all linked functions which have name starting with your prefix and create small module which will execute each of them and link it with final application. Then this module can be activated from our main() function. Probably for flexible usage such modification should be integrated with hbmk2. > 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? See above. It does not work and it was never working. The easiest way is looking for some platform dependent method which allows to activate some initialization code. Usually such trick exists though sooner or later we will find platform where we do not find any native solutions. BTW SunPRO C in Linux builds does not properly executes all constructors. It simply ignores some of them. This bug causes that hbtest in Linux SunPRO C builds GPFs. I hope it will be fixed in SunPRO C compiler in the future (this is very serious bug which also breaks C++ static constructors) so it was not enough motivation for me to look for alternative initialization methods in this builds. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
