On Fri, 11 Sep 2009, Szak�ts Viktor wrote:
> Hi Przemek and all,
> Any opinion on this?
>> We can stated that '-fpic' or '-fPIC' is necessary for 'so'-es. The 
>> '-fpic' generates a smaller and faster code as it is stated in 
>> http://people.redhat.com/drepper/dsohowto.pdf.
>> If the '-fpic' doesn't work for a huge 'so' code it, will be signaled by 
>> gcc in its linking time, is not the case on my test distributions.
>> The build time is not so long on my linux systems, so the method proposed 
>> by Viktor is plausible [Sorry, I lost this info or I can't realize the 
>> interdependencies]. The other proposal is to use '-fpic' or '-fPIC' [-fpic 
>> my option] as default and optionally without, is maybe the easiest IMO.

In practice in all builds we need separate compilation for shared library.
On some platforms/CPUs modules compiled without switches to force position
independent code can work in some limited way but sooner or later they
creates troubles so we should always use switches to force PIC for modules
used to create shared library.
The difference between -fPIC and -fpic is platform/CPU dependent.
Usually -fpic introduce smaller overhead then -fPIC with the cost of
some limitations, like smaller symbol table or maximum code side
though there are platforms where there is not difference between
them or where both are ignored because generated code is always
position independent. Limits introduced by -fpic should be verified
at link time but on some platforms they may depends also on other
libraries so it's safer for general distributions to use -fPIC.
But such decision should be taken by developers working with
given platform/CPUs. We can use for some architectures -fPIC and
on some others -fpic as default settings. We can also start with
-fpic and then switch to -fPIC when user reports problems just like
now we are increasing page side in some library tools.

best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to