[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why kdelibs4-dev and XFree86 4.3.0 don't play nice together (was: Re: xlibs-pic)

>> This was my understanding as well. As I understand the situation, -fPIC
>> preferable to the non-PIC code which was there before.
>It's not quite that simple. This is about static libraries, which policy
>requires to be built without -fPIC. The problem arises when linking them
>into shared objects, for which there's xlibs-pic, like other -pic
Ah! I see, Ted. (Do you really, Dougal? Uhm, No, not really.)

Can you tell that I only know about PIC from a course in O/S's? I'd be
really interested in a proper explaination for this.

I know that PIC code is 'supposed' to be better in that it can be loaded
into memory without regard to the actual location or layout. Why should
static libraries be built without -fPIC, and who's policy is it anyway?

And why are static lib's being linked into shared objects? shouldn't they
be using shared libs instead? I've been playing with Linux From Scratch
which makes extensive use of statically compiled packages for building a
system within a chroot environment without glibc installed in it, so I've a
small understanding of the differences between shared and static, but I
thought, given an option, shared were generally better for system and
memory useage.

>> As for up-stream only caring about i386, that's why it's called XFree86.
>No, actually, it's called XFree86 as a pun on X386. Portability has
>always been a goal of XFree86.
I see. That's a bit different from the understanding I had. I thought that
X, from X.org was based on the original X created by Xerox's Palo Alto
Research Centre for the various UNIX systems. And XFree86 was created from
the latest free version of X primarily for the *86 platform, hence XFree86.
And then Debian, along with others provided extensive work to port this to
other platforms that Linux can run on, as well as the various BSD people
doing the same for their systems. And then these porting changes were being
pushed back up-stream to XFree86 as long as they didn't interfere with the
*86 stuff.

>> The XFree86 team only works on *86 stuff and Debian provides the
>> of the porting work for other archs. Hence Brandan's heavy work load.
>It's certainly true that Debian still supports more architectures than
>XFree86 upstream though.
Yes, and the X-Strike force certainly do a wonderful job ensuring that
XFree86 can support as many arch's as possible.

Thanks for the explainations! It's good to know where all these things come
from and where they are heading.


      John Gay

Reply to: