On Wed, 2003-06-04 at 02:25, John Gay wrote:
>
> >> And why are static lib's being linked into shared objects?
> >
> >Because some shared libraries (or plugins, or whatever) use some X
> >extension libraries which are only available in static form. But non-PIC
> >code in a shared object is a bad i
On Tuesday 03 June 2003 23:05, Frank Van Damme wrote:
> ...which brings up the question: wtf is PIC? :)
[P]osition [I]ndependant [C]ode. On x86 it is a little bit slower than
normal code since the data section is accessed using the ebx register
as index. The result is that the compiler has less po
On Wed, Jun 04, 2003 at 12:51:34AM +0100, John Gay wrote:
>
> >> This was my understanding as well. As I understand the situation, -fPIC
> is
> >> 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 b
"John Gay" <[EMAIL PROTECTED]> writes:
> 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?
Position-independent code requires
>> 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?
>
>Debian's. I guess the reason is that PIC code usually performs worse
On Wed, 2003-06-04 at 01:51, John Gay wrote:
> >> This was my understanding as well. As I understand the situation, -fPIC
> is
> >> 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
>> This was my understanding as well. As I understand the situation, -fPIC
is
>> 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
On Tue, 2003-06-03 at 23:45, John Gay wrote:
> >> 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 e
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, wh
>> 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
>
>Hmm,
On Tuesday 03 June 2003 11:20, Daniel Stone wrote:
> > ... 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
On Tue, Jun 03, 2003 at 07:20:07PM +1000, Daniel Stone wrote:
> > ... 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
On Tue, Jun 03, 2003 at 11:16:30AM +0200, Frank Van Damme wrote:
> it seems your packages for X don't have a package "xlibs-pic". Does this have
> a reason? kdelibs4-dev in Sid depends on it.
There is, indeed, a reason - see below.
> Sorry, but the following packages have unmet dependencies:
>
13 matches
Mail list logo
