Bug 989517
Summary: | glibc-2.17.90-6.fc20 fails to build with /usr/lib/locale: No such file or directory | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Horák <dan> |
Component: | glibc | Assignee: | Carlos O'Donell <codonell> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | rawhide | CC: | codonell, dan, ffesti, fweimer, jakub, jzeleny, law, novyjindrich, ovasik, packaging-team-maint, pfrankli, pknirsch, pmatilai, schwab, spoyarek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | s390x | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-08-06 21:36:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dan Horák
2013-07-29 12:27:45 UTC
ppc64 also uses /usr/lib/locale for -DLOCALEDIR= I'm looking at this. We've been rearranging the glibc.spec file in order to complete the "Move to /usr" transition which was never done for glibc. Dan mentioned on IRC that this failure occurs with glibc-2.17.90-4.fc20 too, so it's not the spec file rearrangement. -DLOCALEDIR is set to /usr/lib64/locale instead of /us/lib/locale, which seems to be a build options change. A good place to look would be the changes made in rpm-build macros. The glibc build expects all architectures to install locales into `/usr/lib/locale'. There is no allowance for this being dynamic and it doesn't change based on the target. It is possible to force the glibc build to install the locales into a directory other than `/usr/lib/locale' via `LOCALEDIR' but doing so is not supported by the glibc rpm. The glibc build failures are an indication that the above expectation has been violated. We should really add asserts into the glibc build with sensible error messages to point out which things are not expected to change. I'm moving this to `rpm' component to see if we can get some input about the s390x locale directory change. Well, lib64 getting used where lib is expected is generally a packaging issue of using %{_libdir} (or %{_lib}) macro where hardcoded "/usr/lib" (or "lib") is needed. Rpm doesn't set LOCALEDIR or such, and there's no macro for the unchanging /usr/lib path. I dont see anything obvious in glibc.spec that would cause such an issue specifically on s390 but that doesn't mean much, considering how complex the spec and filelist generation in there is. Comment #2 mentions rearranging the glibc.spec recently, perhaps you should try reproducing with an older glibc version to catch out possible spec change regressions? it will be probably more complicated because - recent glibc could be built within F-19 buildroot, but not in F-20 - pre-reorg glibc also failed in F-20 but I will look more carefully in the logs, buildroots, etc, what could be different Hmm, rpm between F19 and rawhide is virtually identical. Looking at the actual diff, the only thing from rpm-side that could affect things like this is that in rawhide, autoconf config.site processing is disabled (see bug 962837), in F19 its not. Looking at the root.log from the failed attempt: DEBUG util.py:257: rpm s390x 4.11.0.1-7.fc20 build 1.1 M That version of rpm is not yet setting CONFIG_SITE=NONE which I suppose could cause stuff going wrong. There is sufficiently new rpm on s390 now (although this is still behind real rawhide): http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=192859 Me thinks this is likely just an issue with the s390(x) builds being out of sync wrt rest of Fedora. thanks for the ideas, Panu, I'll try a build with the latest rpm (In reply to Panu Matilainen from comment #5) > Well, lib64 getting used where lib is expected is generally a packaging > issue of using %{_libdir} (or %{_lib}) macro where hardcoded "/usr/lib" (or > "lib") is needed. Rpm doesn't set LOCALEDIR or such, and there's no macro > for the unchanging /usr/lib path. I dont see anything obvious in glibc.spec > that would cause such an issue specifically on s390 but that doesn't mean > much, considering how complex the spec and filelist generation in there is. What sets and passes CFLAGS down to the rpm build? Something, other than the glibc.spec file, sets -DLOCALEDIR=\"/path/\" in CFLAGS which alters the glibc package build, and causes the package to build with a locale directory that isn't what the spec file expects. The solution is to fix whatever is setting -DLOCALEDIR to select the right path e.g. /usr/lib/locale. (In reply to Carlos O'Donell from comment #10) > What sets and passes CFLAGS down to the rpm build? Not rpm, because glibc.spec doesn't use %configure macro. And even with %configure used, rpm only sets various arch/optimization flags, never anything like LOCALEDir (see 'rpm --eval %{optflags}') > Something, other than the glibc.spec file, sets -DLOCALEDIR=\"/path/\" in > CFLAGS which alters the glibc package build, and causes the package to build > with a locale directory that isn't what the spec file expects. > > The solution is to fix whatever is setting -DLOCALEDIR to select the right > path e.g. /usr/lib/locale. Grepping around glibc sources I see: ./locale/Makefile:locale-CPPFLAGS = -DLOCALEDIR='"$(localedir)"' \ ./intl/Makefile:CPPFLAGS += -D'LOCALEDIR="$(msgcatdir)"' \ Rpm's %configure doesn't set explicitly set autoconf's localedir, and glibc.spec doesn't even use that. This does seem like something that autoconf's config.site processing could affect (see comment #7 and #8). So I'd suggest just try rebuilding it now that rpm + autoconf should be "compatible" in the s390 koji. new scratch build [1] with rpm-4.11.1-1.fc20.s390x in the buildroot looks good now, it has -DLOCALEDIR='"/usr/lib/locale"' on s390x, thanks Panu [1] http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1128083 (In reply to Panu Matilainen from comment #11) > (In reply to Carlos O'Donell from comment #10) > > What sets and passes CFLAGS down to the rpm build? > > Not rpm, because glibc.spec doesn't use %configure macro. And even with > %configure used, rpm only sets various arch/optimization flags, never > anything like LOCALEDir (see 'rpm --eval %{optflags}') Perfect, thanks for clarifying that. > > Something, other than the glibc.spec file, sets -DLOCALEDIR=\"/path/\" in > > CFLAGS which alters the glibc package build, and causes the package to build > > with a locale directory that isn't what the spec file expects. > > > > The solution is to fix whatever is setting -DLOCALEDIR to select the right > > path e.g. /usr/lib/locale. > > Grepping around glibc sources I see: > ./locale/Makefile:locale-CPPFLAGS = -DLOCALEDIR='"$(localedir)"' \ > ./intl/Makefile:CPPFLAGS += -D'LOCALEDIR="$(msgcatdir)"' \ Right, but these are derived from $(localedir) which glibc doesn't set but gets from the options passed to configure, or automatically computed and set by autoconf. > Rpm's %configure doesn't set explicitly set autoconf's localedir, and > glibc.spec doesn't even use that. Agreed. > This does seem like something that autoconf's config.site processing could > affect (see comment #7 and #8). So I'd suggest just try rebuilding it now > that rpm + autoconf should be "compatible" in the s390 koji. Agreed. (In reply to Dan Horák from comment #12) > new scratch build [1] with rpm-4.11.1-1.fc20.s390x in the buildroot looks > good now, it has -DLOCALEDIR='"/usr/lib/locale"' on s390x, thanks Panu > > [1] http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1128083 Given that the build completed are you opposed to marking this issue as CLOSED/CURRENTRELEASE? please close as stated |