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

Reply via email to