Several times in the past we have seen requests to build libraries
with the -fPIC flag for which XFree86 doesn't supply shared versions.
These requests have always been turned down so far for two reasons:
1. XFree86 wants to discourage anyone from turning the static libraries
into shared ones.
These libraries are still under development and thus their API
subject to change.
XFree86 wants to ensure the APIs can still be modified without
having to worry about providing backward compatibility. This
would no longer be possible if the libraries were shared.
2. Position independent code (PIC) performs somewhat lower than
non-PIC. PIC requires one CPU register to hold offset information.
Thus this register is no longer available to the code itself.
Recently I have been approached by the KDE project about this issue again.
1. In order to provide the functionality of these libraries thru the
context of their API KDE fully wraps this libraries' APIs.
Thus any call from a KDE application to these libraries
is done thru functions provided by a shared library of this
toolkit.
Direct calls of the XFree86 libs are not permitted.
However to do so the XFree86 libraries need to be linked
into the shared libs these projects provide.
2. The ABI of the currently most widely used platform (IA32) does
not require objects to be position independent when being linked
into shared libraries.
This is not true however for some platforms like IA64, PPC,
x86-64 or AXP.
To make toolkits like KDE work on these distribution vendors
have added more or less nasty kludges to their XFree86 build
configuration to either create shared versions of all XFree86
libraries or create a PIC version of these.
As most GUI toolkits were developed on IA32 this problem has
never been realized until these toolkits were ported to other
platforms.
Reviewing these arguments I arrived at the following conclusion:
A. PIC .a libraries themselves are not usable as shared libs.
B. The performance issue matters significantly only on IA32.
All platforms that require PIC objects to build shared
libraries have a sufficiently large number of CPU registers
that performance penalties are negligible.
C. A fully encapsulated XFree86 library API doesn't place any
more burden on XFree86 to provide any more backward compatibility
than statically linked libraries.
I therefore propose the following procedure:
A. Identify all XFree86 libraries whose may be encapsulated
by toolkits shared libraries without being shared themselves.
B. Compile libraries identified in 1. with -fPIC on platforms
that require position independent code for shared libraries.
C. Always require a full encapsulation of the API when a static
XFree86 library is added to a shared toolkit library.
Thus:
a. Toolkit designs that need to expose any part of
this ABI are considered broken.
b. Applications that reference any part of this ABI
bypassing the toolkit are considered broken.
I would like to get feedback from the community on this.
After talking this over with David I have implemented and committed
it to the XFree86 CVS. However David suggested to discuss this
in public.
Should any serious objections arise We can still modify/remove it
before 4.3 comes out.
Egbert.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
