OK, You are right Przemek, the real problem was an old pptable.c not deleted by "clean" nor by the make rules. As I discovered some old files within my system I deleted them at the same time I changed my envar so the confusion.
Just to be sure, do you know wich other file(s) should be checked ? Regards, JF, -----Message d'origine----- De : harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] De la part de Przemyslaw Czerpak Envoyé : vendredi 13 mars 2009 16:51 À : Harbour Project Main Developer List. Objet : Re: [Harbour] unresolved external symbol _HB_FUN_HB_SYMBOL_UNUSED(SOLVED) On Fri, 13 Mar 2009, Juan Gálvez wrote: Hi, > BTW, I also get this error building Harbour : > ../../../../source/main/win/bcc/harbour.exe ../../hbrun.prg -n1 > -i../../../../include -q0 -w3 -es2 -km -l -gc0 -l > bcc32.exe -I. -I../../../../include -q -d -Q -w -w-sig- -tWM -4 -O2 -OS -Ov > -Oi -Oc -DHB_FM_WIN_ALLOC -DHB_HASH_MSG_ITEMS -DHB_DYNLIB > -DHB_NO_PROFILER -c hbrun.c -ohbrun.obj > hbrun.c: > bcc32.exe -q -d -Q -w -w-sig- -tWM -4 -O2 -OS -Ov -Oi -Oc -ehbrun.exe > hbrun.obj -L../../../../lib/win/bcc ../../../../lib/win/bcc/hbextern.lib > ../../../../lib/win/bcc/gtwvt.lib ../../../../lib/win/bcc/gtgui.lib > Error: Unresolved external '_HB_FUN_HB_SYMBOL_UNUSED' referenced from > C:\UTL\HARBOUR\LIB\WIN\BCC\HBRTL.LIB|tget > Any hints ? Each of you with this problem has own customized std.ch which is used instead of the one in harbour/include directory or the harbour/include/std.ch file is modified. It's not Harbour problem but user local environment settings which cause that wrong std.ch is built into the Harbour compiler. So far (it's even possible that for quite long time) you were created wrong binaries. Recent modification which need one rule from original std.ch exploited the problem so at least now you can fix it and create correwct harbour binaries. The question is why wrong std.ch is used instead the original Harbour one (I hope that you haven't modified the original file). So far I know only three methods: 1. set different std.ch in CLIPPER or HARBOUR environment variable, f.e.: set CLIPPER=/umystd.ch or: set HARBOUR=/umystd.ch Viktor added protection against it (it clears above both variables) to build scripts. 2. HB_PP_RULES which can be used in some cross compilation points to wrong pptable.c file which is used instead of file dynamically generated. Do not ever try to use this variable as long as you do not know exactly how to create your own customized cross compilation environment. It's for developers only. 3. You have some old pptable.c file in harbour/source/pp/ directory which is used instead of the one generated dynamically by hbpp during compilation. It's possible that some old version of non GNU make files left such pptable.c in harbour/source/pp/ directory. Remove if it exists. Recently JF suggested that the problem can be exploited also by setting INCLUDE envvar. I cannot replicate it and confirm. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
