dev-libs/poco-1.4.3_p1 fails to compile with dev-libs/libpcre-8.32 because of an undefined symbol /var/tmp/portage/dev-libs/poco-1.4.3_p1/work/poco-1.4.3p1-all/lib64/libPocoFoundationd.so: undefined reference to `_pcre_ucd_stage1' /var/tmp/portage/dev-libs/poco-1.4.3_p1/work/poco-1.4.3p1-all/lib64/libPocoFoundationd.so: undefined reference to `_pcre_ucd_records' /var/tmp/portage/dev-libs/poco-1.4.3_p1/work/poco-1.4.3p1-all/lib64/libPocoFoundationd.so: undefined reference to `_pcre_ucp_gentype' /var/tmp/portage/dev-libs/poco-1.4.3_p1/work/poco-1.4.3p1-all/lib64/libPocoFoundationd.so: undefined reference to `_pcre_ucd_stage2' full build.log and emerge --info attached. Reverting to dev-libs/libpcre-8.31 resolves the problem.
Created attachment 332212 [details] build.log.bz2 build.log with MAKEOPTS="" as the error message is more clear.
Created attachment 332216 [details] emerge --info
Well, this seems to go under "using internal functions is bad for you in the long run". Looks like an upstream bug.
Broken "solutions" aside, this could be marked as a dupe of bug 446245, on the other hand, at least there's a build log here.
Version for libpcre restricted to <=8.31
(In reply to comment #5) > Version for libpcre restricted to <=8.31 So why is this marked as FIXED then, when it's not? Should also block the tracker bug 414997 for these violations
Also downgrading pcre can be really risky due problems like bug 419795 (it can break grep, that prevents you from emerging anythin). I would then drop the blocker even causing this to fail to build, while keeping the rest of the system working CCing QA team as I think that, even if downgrades are allowed in some cases, they should be forbidden (maybe with a repoman warning) in special cases like pcre, as downgrading it can lead to an important breakage
I can probably say many times that I don't want packages restricting older versions of libraries, but the Council decided to overstep me so...
(In reply to comment #8) > I can probably say many times that I don't want packages restricting older > versions of libraries, but the Council decided to overstep me so... Maybe most people could agree on restricting it for some "basic" libs while not considering it forbidden in general... I also suggested in the past to not enable by default "pcre" USE flag for grep but it was also rejected :S
I can only show the door.. anyway in this case I would just say that either it's possible to fix this quickly, or upstream really screwed up.
(In reply to comment #10) > I can only show the door.. anyway in this case I would just say that either > it's possible to fix this quickly, or upstream really screwed up. Well, looks like fedora people are not having problems with poco+pcre-8.30 :/ http://pkgs.fedoraproject.org/cgit/poco.git/tree/poco.spec Will CC pcre maintainers and portage people to let them show other possible ways to prevent breakage if we finally allow people to force downgrade of pcre. For now, maybe using preserve_lib stuff (from eutils.eclass, as portage functionality is still disabled by default in stable portage) could prevent the breakage
(In reply to comment #11) > (In reply to comment #10) > > I can only show the door.. anyway in this case I would just say that either > > it's possible to fix this quickly, or upstream really screwed up. > > Well, looks like fedora people are not having problems with poco+pcre-8.30 :/ No wonder, since libpcre up to 8.31 does work fine, it is 8.32, which breaks poco and because of this all poco users (which btw is not catched by the @preserved-rebuild feature of portage, so you only notice the failure, when you want to start a poco user after upgrading to libpcre-8.32). So while downgrading libpcre may cause issues, not downgrading will keep poco and everything using poco broken, which cant be a good solution either.
I just looked at the Tracker bug and this doesnt look like a matching bug, since poco-1.4.3_p1 is a stable package, which works fine with stable libpcre-8.30-r2, the issue only happens with testing libpcre versions (8.31 works, 8.32 breaks poco).
(In reply to comment #11) > Will CC pcre maintainers and portage people to let them show other possible > ways to prevent breakage if we finally allow people to force downgrade of > pcre. For now, maybe using preserve_lib stuff (from eutils.eclass, as > portage functionality is still disabled by default in stable portage) could > prevent the breakage It looks like all versions of dev-libs/libpcre have SLOT=3. Maybe you can bump the SLOT so that libpcre-8.32 can be installed simultaneously with the older version of libpcre? That's normally how we handle incompatible changes to libraries.
Have anybody tried if poco-1.4.5 is also incompatible with latest pcre? (our version in the tree is a bit outdated)
(In reply to comment #15) > Have anybody tried if poco-1.4.5 is also incompatible with latest pcre? (our > version in the tree is a bit outdated) That should have been the first step and prerequisite for proceeding with Comment #5. Not doing so makes poco a lastrite candidate.
We can't change the slot because the SONAME between 8.31 and 8.32 does not change, but it does break the ABI because of hiding internal functions that shouldn't have been there to begin with. Thus why preserved-libs is not hitting it.
(In reply to comment #15) > Have anybody tried if poco-1.4.5 is also incompatible with latest pcre? (our > version in the tree is a bit outdated) poco-1.4.5 is in the tree and has the same issue
Well, the problem seems to come from Foundation/src/Unicode.cpp. There, in void Unicode::properties(int ch, CharacterProperties& props), GET_UCD macro is used. That's macro is defined in pcre_internal.h - obviously pcre upstream did not intend to make it available for lib consumers. However, there doesn't seem to be any other way to access that data now that those symbols are hidden and that function is part of poco API. Upstreams need to agree now - what are the chances of "let's *always* bundle it" being poco's solution ?
Since i now added 1.4.5-r1 with a patch allowing libpcre-8.32 and 1.4.3_p1 being a stable package working with the latest stable version of libpcre (8.30-r2), i see nothing left here to do, so closing. Short summary: -stable users should use stable version of both packages -testing users should use testing versions of both packages
