On Sun, 09 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
> I see. Do you know which platforms are those? F.e. Linux. For shared binaries -fPIC or -fpic should be used in most of architectures. It forces relocatable code but with the cost of speed. Relocatable cost is a little bit less efficient. In [EMAIL PROTECTED] it's still possible to create Harbour shared library from binaries compiled without -fPIC because we do not have any code which cannot be converted and GCC does the conversion automatically when harbour.so is created. For 64bit -PIC is enabled automatically for all builds with the cost of speed because GNU make does not support separated compilation for shared and static libraries :-( -fPIC is necessary in most of *nixes. > The same thing I've already posted. The only way > hbrun-dll.exe can be built now is to use > 'set C_USR=-DHB_DYNLIB' Why? What is the error? >> For me it's not a problem but please remember that you should >> not remove such functionality from make files because it may >> be necessary in some situations. We should also remember about > Which can these be? most of *nixes. And to be precise in all platforms where C compiler can make some additional optimizations for given CPU which cause that the final code stop to be relocatable. Without separate compilation for Harbour shared library these optimizations cannot be enabled. (in GCC on some platforms they are enabled by default and have to be diabled -fPIC or -fpic) See GCC documentation for more information. Please look also at -mno-shared. We do not use it yet. >> builds for environments with restrictive memory amount, f.e. >> for WinCE where probably also -gc3 should be replaced with -gc0 >> and in MinGWCE -O3 GCC switch replaced by -O2. > Committed, but not tested. (no WinCE capable compiler > around here. Except POCC which doesn't really work yet) > Do you think it's alright to remove the second pass for BCC/MSVC? AFAIK it should not have any other side effects then bigger binaries and public access for exported Harbour functions. But it's also possible that it will have some impact on optimizations in these compiler. I do not know if they can create non position-independent code to increase the speed. But please make it by simple DLL_OBJ_DIR=$(OBJ_DIR) executed optionally so people who want to tuned final Harbour binaries for optimal code size can easy use current form. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour