| Summary: | >=dev-libs/icu-58.1-r1 fails to compile in hardened/linux/musl/amd64 profile | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chad Joan <chadjoan> |
| Component: | Hardened | Assignee: | Gentoo musl team <musl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | herrtimson |
| Priority: | Normal | Keywords: | InOverlay |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 430702 | ||
| Attachments: |
build.log
emerge --info '=dev-libs/icu-58.2::gentoo' emerge -pqv '=dev-libs/icu-58.2::gentoo' |
||
|
Description
Chad Joan
2017-01-04 07:19:23 UTC
Created attachment 458634 [details]
emerge --info '=dev-libs/icu-58.2::gentoo'
Created attachment 458636 [details]
emerge -pqv '=dev-libs/icu-58.2::gentoo'
The versions from the musl overlay should work fine for you. This bug is also reported upstream: http://bugs.icu-project.org/trac/ticket/12851 Hmmm, I don't see versions in the musl overlay.
Here is what comes up for dev-libs/icu:
$ eix -e icu
[I] dev-libs/icu
Available versions: 55.1(0/55) 57.1(0/57) [m]58.1-r1(0/58.1) [m]~58.2(0/58.2) {debug doc examples static-libs ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
Installed versions: 57.1(02:17:43 01/04/17)(-debug -doc -examples -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
Homepage: http://www.icu-project.org/
Description: International Components for Unicode
By comparison, here is gcc, which I will use to demonstrate that the musl overlay is present elsewhere:
$ eix -e gcc
[I] sys-devel/gcc
Available versions:
(2.95.3) [m]~*2.95.3-r10^s
(3.3.6) [m]~3.3.6-r1^s
(3.4.6) [m]3.4.6-r2^s
(4.0.4) [m]**4.0.4^s
(4.1.2) [m]4.1.2^s
(4.2.4) [m]~4.2.4-r1^s
(4.3.6) [m]4.3.6-r1^s
(4.4.7) [m]4.4.7^s
(4.5.4) [m]4.5.4^s
(4.6.4) [m]4.6.4^s
(4.7.4) [m]4.7.4^s 4.7.4-r99^s[1]
(4.8.5) [m]4.8.5^s 4.8.5-r99^s[1] 4.8.5-r999^s[1]
(4.9.3) [m]4.9.3^s 4.9.3-r99^s[1] **4.9.3-r999^s[1]
(4.9.4) [m]4.9.4^s
(5.1.0) [m]**5.1.0^s
(5.2.0) [m]**5.2.0^s
(5.3.0) [m]~5.3.0^s
(5.4.0) [m]~5.4.0^s [m]~5.4.0-r2^s
(6.1.0) **6.1.0^s[1]
(6.3.0) [m]**6.3.0^s
{altivec awt boundschecking cilk +cxx d debug doc fixed-point +fortran gcj go graphite hardened jit libssp mpx mudflap multilib multislot +nls nopie nossp +nptl objc objc++ objc-gc +openmp (+)pch pie regression-test +sanitize (+)ssp vanilla +vtv}
Installed versions: 4.9.3-r99(4.9.3)^s[1](00:46:50 08/28/16)(cxx fortran gcj hardened nptl openmp -altivec -awt -cilk -debug -doc -fixed-point -go -graphite -libssp -multilib -multislot -nls -nopie -nossp -objc -objc++ -objc-gc -regression-test -sanitize -vanilla)
Homepage: https://gcc.gnu.org/
Description: The GNU Compiler Collection
[1] "musl" /var/lib/layman/musl
Thanks!
Are you sure that your copy of the musl overlay is up to date? Note that the version of sandbox that you are using does not exist anymore. I ran eix-sync that day. That should give me updated trees in portage and all overlays, right? If not, how do I update my update? Below is the URL that I am pulling my musl overlay from. Perhaps it is out of date, or I picked the wrong one somehow? $ layman -l * musl [Git ] (git://anongit.gentoo.org/proj/musl.git) eix-sync should sync everything if "*" is in /etc/eix-sync.conf, or indirectly when /etc/portage/repos.conf is set up for all overlays. The url for the musl overlay is correct. I can't confirm those above things: I don't have an /etc/eix-sync.conf file and /etc/portage/repos.conf is a directory containing gentoo.conf and local.conf.
If I run `eix --dump | grep -i sync` then I get this:
# This variable is used for delayed substitution in EIX_SYNC_CONF.
# It contains code which is evaluated by eix-sync, so be aware of security!
EIX_SYNC_OPTS=""
# The content of this variable is appended to /etc/eix-sync.conf
# Parts of this variable are evaluated in eix-sync: Be aware of security!
EIX_SYNC_CONF="%{EIX_SYNC_OPTS}"
# This file is the previous eix cache (used by eix-diff and eix-sync).
So I don't think it gets the *.
However, I am pretty sure it is updating musl. When I run `eix-sync`, I see this text among other things:
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
Reading category 163|163 (100) Finished
[1] "musl" /var/lib/layman/musl (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
Reading category 163|163 (100) Finished
[2] "local" /usr/local/portage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
Reading category 163|163 (100) Finished
I think it is picking up the "/var/lib/layman/musl" in /var/lib/layman/make.conf. I suspect I set it up that way so that layman can manage its own references, or maybe documentation somewhere told me to do it ;)
I do really wish I knew why we see different overlay contents, since this could have a profound impact on what I report in the bug tracker.
I should probably mention that while my sandbox version seems non-existent to you, it is most recent (stable) from my view of the universe:
$ eix -e sandbox
[I] sys-apps/sandbox
Available versions: 2.6-r1 2.6-r999[1] ~2.7 ~2.8 ~2.9 2.10-r1 ~2.10-r2 ~2.10-r3 2.10-r99[1] [M]~2.11-r3 [M]~2.11-r4 {multilib ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
Installed versions: 2.10-r99[1](12:32:53 08/04/16)(-multilib)
Homepage: http://www.gentoo.org/proj/en/portage/sandbox/
Description: sandbox'd LD_PRELOAD hack
[1] "musl" /var/lib/layman/musl
This is right after I ran eix-sync to get the above "Building database" text.
Sorry for bringing a weird configuration problem. o.O
And thanks for helping with it.
I am very sure that your copy of the musl overlay is not being synced. sandbox-2.6-r999 was removed on Nov 17. Please take a look at https://wiki.gentoo.org/wiki/Eix#Method_2:_Using_eix-sync Or alternatively refer to https://wiki.gentoo.org/wiki//etc/portage/repos.conf on how to set up /etc/portage/repos.conf . Make sure that the musl overlay has higher priority than the main tree. I don't think it is has hurted to report this bug since it also tracks the upstream issue with icu. I am very sure that you're right.
I read those links, and I think the * in /etc/eix-sync.conf did the trick for this system.
Now I see some steps in eix-sync that I did not see before:
[...]
delete mode 100644 x11-libs/libva-vdpau-driver/files/libva-vdpau-driver-0.7.4-nouveau.patch
rename x11-libs/libva-vdpau-driver/{libva-vdpau-driver-0.7.4-r99.ebuild => libva-vdpau-driver-0.7.4-r4.ebuild} (93%)
delete mode 100644 x11-libs/vte/files/vte-0.42.4-fix-musl-NULLs.patch
delete mode 100644 x11-libs/vte/vte-0.42.4-r99.ebuild
create mode 100644 x11-misc/slim/files/slim-1.3.6-envcpy-bad-pointer-arithmetic.patch
create mode 100644 x11-misc/slim/files/slim-1.3.6-freetype.patch
rename x11-misc/slim/{slim-1.3.6-r99.ebuild => slim-1.3.6-r5.ebuild} (65%)
*
* Succeeded:
* ------
* Successfully synchronized overlay "musl".
*
And I see musl overlay entries for dev-libs/icu:
$ eix -e icu
[I] dev-libs/icu
Available versions: 55.1(0/55) 57.1(0/57) [m]58.1-r1(0/58.1) [m]58.1-r1(0/58.1)[1] [m]~58.2(0/58.2) [m]~58.2(0/58.2)[1] {debug doc examples static-libs ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
Installed versions: 57.1(02:17:43 01/04/17)(-debug -doc -examples -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
Homepage: http://www.icu-project.org/
Description: International Components for Unicode
[1] "musl" /var/lib/layman/musl
Overlay priorities seem fine to my eyes:
$ emerge --info --verbose | sed -n '/^Repo/,/^ABI/p' | head -n -1
Repositories:
gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
musl
location: /var/lib/layman/musl
masters: gentoo
priority: 0
local
location: /usr/local/portage
masters: gentoo
priority: 1
...
I'll have to do some unmasking/updating later.
So, uh, neglecting to put * into /etc/eix-sync.conf is kind of disastrous. Oh my. Thanks so much for helping me figure that out.
I think this bug can be closed, right? (In reply to tt_1 from comment #12) > I think this bug can be closed, right? No objections here. The reporter can close this bug as well, and in this case should, if it has been resolved. |