Your mailer appears to be breaking threading. Can you fix that, or use
a mailer that doesn't?
--
G. Branden Robinson| The last Christian died on the
Debian GNU/Linux | cross.
[EMAIL PROTECTED] | -- Friedrich Nietzsche
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 new
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, I thought
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 easy way to
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
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
than
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 the
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 be built
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 be built
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 idea, it
Your mailer appears to be breaking threading. Can you fix that, or use
a mailer that doesn't?
--
G. Branden Robinson| The last Christian died on the
Debian GNU/Linux | cross.
[EMAIL PROTECTED] | -- Friedrich Nietzsche
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:
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:
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 new
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, I thought
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 easy way to
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 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 -fPIC. The
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
than
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 the
20 matches
Mail list logo
