Re: Why kdelibs4-dev and XFree86 4.3.0 don't play nice together (was: Re: xlibs-pic)
Sorry, meant to send this to the list.
>> > ... I downgraded xlibs and xbase-clients in order to install
>> > kdelibs4-dev.
>>
>> Yeah, that's because kdelibs4-dev depends on XFree86 4.2.1, and won't
>> work with 4.3, due to the different way we handle PIC (this is
>> upstream's shiny new way, which I'm assured is wrong, but that's beside
>> the point). There's no real easy way to get kdelibs4-dev to install with
>> my packages, unfortunately.
>
>
>...which brings up the question: wtf is PIC? :)
>
I'm no expert, but as I understand it:
PIC is Position Independant Code. It means that the code contains only
relative jumps, loops and branch statements so that when it is loaded into
memory, it does not matter where in memory it is put or even if it is split
into non-sequential pages of memory as the underlying O/S can handle the
jumps.
In the past, major sections of the GL libs could not be compiled as PIC. It
contained absolute jumps that required the O/S to load the code into a
particular memory setup. This creates many problems with certain tools,
expecially optimizations and object pre-loading, as well as certain
headaches for QT libs.
In an Ideal world, all code would be PIC, but sometimes it's difficult to
program that properly. Of course all of this is related to how memory
management is handled at the processor level, so this creates even more
trouble when trying to create truly portable code as well.
>> So, this is the canonical answer: it won't install right now,
>> unfortunately.
>
>I can live with the current situation. After all, who cares about those X
>clients with a last modification date in 1987 to be 4.2.1 or 4.3 ;-)
>
I'm sure there are others who know even more about this than I do who can
give better explainations. I'm interested in hearing more on this subject
as well.
Cheers,
John Gay
Reply to: