On Mar 3, 2011, at 7:09 AM, Qing He wrote: >> >> The only way that backtrace can happen (that I can see) is if RPM, not >> zypper, is mis-compiled >> using an unfixed (to redefine colliding symbols) "system: PCRE with >> #include <pcreposix.h> >> >> which leaves you two choices: >> >> 1) fix you "system" PCRE <pcreposix.h> >> 2) build --with-pcre=internal > > This helps a lot, with the patching of "system" PCRE, the problem seems gone. > > The RPM we are using is rpm-5.4.0, which doesn't have an internal pcre > shipped, so I diffed the "system" header with the internal header, and saw > the "#define regcomp pcreposix_regcomp" artifact. >
Yes. You would have to re-add, either by preparing a tarball from a checkout form @rpm5.org, or by adding from elsewhere. The patch to change the pcre emulation is all thai is important. The only other change in the internal pcre @rpm5.org is to disable 'make install" in the pcre sub-tree. There might be some other minor changes to remove compilation warnings. But more distros already have the needed patch in "system" pcre afaik. @redhat systems are the important exception. > It's then much clearer to understand what actually happened, regex_t > from pcreposix.h is used bug regcomp from libc is what get called at > runtime, that causes the failure. > > Interestingly, this patch is also found in Debian, but no versions of > vanilla PCRE. I tried to find some original discussion on the issue, > but got no meaningful result, is there any references? And why PCRE > upstream is sticking to this? > Yes. The patch was taken from Debian originally. I *believe* (from dim memories of checking diff's upgrading pcre) that there's an equivalent change in pcre-8.10 (but I could easily be mis-remembering). >> >> >> >> From what I know of zypper (mostly libsatsolver and tools), the code rips >> everything >> out-of-an-rpmdb and uses as little as possible from RPM libraries. But I >> haven't >> looked for 2+ years. > > Doesn't know much about zypper internals, but the issue above is > triggered with only NULL passing around. > Yes a symbol collision has a pervasive and hard to diagnose effect. Glad to hear the problem was fixed. BTW, rpm-5.4.1 will likely be released in the next week. Be careful how/when you upgrade on the rpm-5_4 branch because that is the "devel" branch. But there's nothing in rpm-5.4.0 that differs significantly from rpm-5.3.8. I will be careful ... but I am soon to get back to more active development. 73 de jeff ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
