RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Dueling symbols using PCRE emulation of POSIX ERE's

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 14 Jan 2009 - 16:54:19 CET
Message-id: <DB842BB0-4D74-4D85-8420-6D05A42B8D01@mac.com>

On Jan 14, 2009, at 10:27 AM, Jeff Johnson wrote:

>>>
>>> That forces MANDATORY INTERNAL PCRE always afaict.
>>
>> There are other methods to avoid this issue, e.g.
>> http://rpm5.org/community/rpm-devel/1562.html
>>
>
> Thank you. I will add identical #defines to rpmio/mire.c
> today, and that will fix the yum+rpmlib problem.

I should supply more details of what I was thinking ...

A patch to external "system" PCRE cannot be assumed by rpm.

Sure patch existence could be tested by AutoFu, and fail to build rpm
if a PCRE patch is not applied to "system" PCRE, but that doesn't really
help anything at all.

What may be possible is "partial static linkage"
against unpatched external "system" PCRE libraries,
or other means to hide the colliding symbols, or restrict
the linker scope so that the required PCRE POSIX emulation
will be found by rpmlib, permitting yum/python to use what they
wish, and permit rpmlib to use PCRE.

If successful, "partial static linkage" will fix the yum+rpmlib problem.

But I still suspect that INTERNAL is far far less complex a solution
than attempting "partial static linkage" everywhere.

Note the multiple portability issues in attempting "partial static  
linkage"
to avoid a symbol clash.

And I have little desire to be forced to advocate applying what is  
otherwise
a sensible patch to avoid a symbol clash in libraries.

73 de Jeff
Received on Wed Jan 14 16:54:22 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.