Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 447108 - dev-libs/poco-1.4.3_p1 with dev-libs/libpcre-8.32 - .../work/poco-1.4.3p1-all/lib64/libPocoFoundationd.so: undefined reference to `_pcre_ucd_stage1'
Summary: dev-libs/poco-1.4.3_p1 with dev-libs/libpcre-8.32 - .../work/poco-1.4.3p1-all...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Thomas Sachau
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 414997
  Show dependency tree
 
Reported: 2012-12-13 13:55 UTC by drhopfen
Modified: 2012-12-21 13:24 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log.bz2 (build.log.bz2,16.92 KB, application/x-bzip)
2012-12-13 13:58 UTC, drhopfen
Details
emerge --info (emerge.info,17.30 KB, text/plain)
2012-12-13 14:03 UTC, drhopfen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description drhopfen 2012-12-13 13:55:56 UTC
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.
Comment 1 drhopfen 2012-12-13 13:58:57 UTC
Created attachment 332212 [details]
build.log.bz2

build.log with MAKEOPTS="" as the error message is more clear.
Comment 2 drhopfen 2012-12-13 14:03:47 UTC
Created attachment 332216 [details]
emerge --info
Comment 3 Rafał Mużyło 2012-12-13 14:24:25 UTC
Well, this seems to go under "using internal functions is bad for you in the long run".

Looks like an upstream bug.
Comment 4 Rafał Mużyło 2012-12-13 14:31:39 UTC
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.
Comment 5 Thomas Sachau gentoo-dev 2012-12-20 16:15:45 UTC
Version for libpcre restricted to <=8.31
Comment 6 Samuli Suominen (RETIRED) gentoo-dev 2012-12-20 16:21:06 UTC
(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
Comment 7 Pacho Ramos gentoo-dev 2012-12-20 19:25:05 UTC
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
Comment 8 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-12-20 19:26:20 UTC
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...
Comment 9 Pacho Ramos gentoo-dev 2012-12-20 19:29:34 UTC
(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
Comment 10 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-12-20 19:30:33 UTC
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.
Comment 11 Pacho Ramos gentoo-dev 2012-12-20 19:40:44 UTC
(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
Comment 12 Thomas Sachau gentoo-dev 2012-12-20 19:53:04 UTC
(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.
Comment 13 Thomas Sachau gentoo-dev 2012-12-20 19:57:24 UTC
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).
Comment 14 Zac Medico gentoo-dev 2012-12-20 20:01:55 UTC
(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.
Comment 15 Pacho Ramos gentoo-dev 2012-12-20 20:07:11 UTC
Have anybody tried if poco-1.4.5 is also incompatible with latest pcre? (our version in the tree is a bit outdated)
Comment 16 Samuli Suominen (RETIRED) gentoo-dev 2012-12-20 20:09:35 UTC
(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.
Comment 17 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-12-20 20:11:58 UTC
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.
Comment 18 Thomas Sachau gentoo-dev 2012-12-20 20:42:42 UTC
(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
Comment 19 Rafał Mużyło 2012-12-20 22:56:25 UTC
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 ?
Comment 20 Thomas Sachau gentoo-dev 2012-12-21 13:24:37 UTC
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