Trying to cross build a root fs from an empty ROOT gives this error: >>> Emerging (1 of 2) sys-libs/timezone-data-2014a::gentoo for /usr/x86_64-tm-linux-gnu/ * tzdata2014a.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * tzcode2014a.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking tzdata2014a.tar.gz to /usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work >>> Unpacking tzcode2014a.tar.gz to /usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work >>> Source unpacked in /usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work >>> Preparing source in /usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work ... * Applying timezone-data-2013h-makefile.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work ... >>> Source configured. >>> Compiling source in /usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work ... make -j9 -l8 -s TOPDIR=/usr 'CFLAGS= -O2 -pipe -std=gnu99' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' LDLIBS= In file included from scheck.c:8:0: private.h:78:40: fatal error: sys/types.h: No such file or directory compilation terminated. In file included from ialloc.c:8:0: private.h:78:40: fatal error: sys/types.h: No such file or directory compilation terminated. In file included from asctime.c:14:0: private.h:78:40: fatal error: sys/types.h: No such file or directory compilation terminated. In file included from localtime.c:13:0: private.h:78:40: fatal error: sys/types.h: No such file or directory compilation terminated. make: *** [ialloc.o] Error 1 make: *** Waiting for unfinished jobs.... make: *** [localtime.o] Error 1 make: *** [asctime.o] Error 1 make: *** [scheck.o] Error 1 In file included from difftime.c:8:0: private.h:78:40: fatal error: sys/types.h: No such file or directory compilation terminated. make: *** [difftime.o] Error 1 zdump.c:21:52: fatal error: stdio.h: No such file or directory compilation terminated. In file included from zic.c:7:0: private.h:78:40: fatal error: sys/types.h: No such file or directory compilation terminated. make: *** [zic.o] Error 1 make: *** [zdump.o] Error 1 emake failed * ERROR: sys-libs/timezone-data-2014a::gentoo failed (compile phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_compile * environment, line 2311: Called die * The specific snippet of code: * emake TOPDIR="${EPREFIX}/usr" CFLAGS="${CPPFLAGS} ${CFLAGS} -std=gnu99" LDFLAGS="${LDFLAGS}" LDLIBS="${LDLIBS}" || die; * * If you need support, post the output of `emerge --info '=sys-libs/timezone-data-2014a::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/timezone-data-2014a::gentoo'`. * The complete build log is located at '/usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/temp/build.log'. * The ebuild environment file is located at '/usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/temp/environment'. * Working directory: '/usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work' * S: '/usr/x86_64-tm-linux-gnu/tmp/portage/sys-libs/timezone-data-2014a/work' This is because tiemzone data needs glibc but glibc has not been built yet. There is no DEPEND on glibc in timezone-data's ebuild
If you need to build anything against a C library (in this case the tz tools) then build a stage3 toolchain with crossdev first: crossdev --help: [...] -s3, --stage3 Also build the C library All the earlier stages have limited use anyway.
This does not help when you define ROOT to some other dir and rebuild from scratch because then there is no glibc to start with. (don't look at my /usr/x86_64-tm-linux-gnu/ path, it has been replaced with a bind mount to an empty dir with only etc/portage in it) It is quite obvious that glibc do not need timezone-data to build. Either timezone-data should be PDEPEND or timezone-data should move into the system profile and its dep be removed from glibc.
One would think thate USE=vanilla would do the trick but vanilla blocks timezone-data so one cannot emerge timezone-data seperatly. Please open this bug again
Reopening as I think the resolution is wrong
sys/types.h is provided by the C library. if your compiler is broken, then random packages are expected to fail. adding circular dependencies won't help either. this is why we have the stage1->stage3 process, and why crossdev bootstraps a sysroot for you. we specifically classify this as not a bug.
(In reply to SpanKY from comment #5) > sys/types.h is provided by the C library. if your compiler is broken, then > random packages are expected to fail. It is not broken, been built with crossdev, no special options. I do use my own sysroot though as the standard sysroot has limitations: 1) you must be root to install pkgs there. 2) you can only have one active branch of development > > adding circular dependencies won't help either. this is why we have the No circluar deps. Is it not possible to only PDEPEND on timezone-data in glibc and then add DEPEND glibc in timezone-data? > stage1->stage3 process, and why crossdev bootstraps a sysroot for you. > > we specifically classify this as not a bug. This sysroot does not always work well due to 1) and 2) above. If the PDEPEND idea does not fly, can the RDEPEND: vanilla? ( !sys-libs/timezone-data ) be removed? Then one can build glibc with USE=vanilla and you can pull in timezone-data manually.
(In reply to Joakim Tjernlund from comment #6) if you want to use your own sysroot, you must take care to initially seed it with a C library crossdev needs to gain support for making it easy to create arbitrary sysroot support for users (rather than only supporting /usr/$CTARGET out of the box). at that point i might reconsider this, but not now.
(In reply to SpanKY from comment #7) > (In reply to Joakim Tjernlund from comment #6) > > if you want to use your own sysroot, you must take care to initially seed it > with a C library yes, this is what I am doing but the odd dependcy for timezone-data is getting in my way. Oddly timezone-data is missing a DEPEND on glibc and glibc has DEPEND+=" !vanilla? ( >=sys-libs/timezone-data-2012c )" RDEPEND+=" vanilla? ( !sys-libs/timezone-data ) !vanilla? ( sys-libs/timezone-data )" There is no real DEPEND for timezone data and why is there a: RDEPEND= vanilla? ( !sys-libs/timezone-data ) This all feel like a workaround for something else but what? > > crossdev needs to gain support for making it easy to create arbitrary > sysroot support for users (rather than only supporting /usr/$CTARGET out of > the box). at that point i might reconsider this, but not now. That would be nice :) Currently I use proot to bind mount my own sysroot over /usr/$CTARGET
(In reply to Joakim Tjernlund from comment #8) historically glibc has provided the timezone data. when we added the sep package, we couldn't just let every system out there stop installing timezone data entirely. even today, there's not really a better place to express this dependency. hence glibc depends on it. and yes, it does utilize /usr/share/zoneinfo at runtime, so glibc RDEPEND-ing on it makes sense. however, timezone-data does not require glibc, so it does not DEPEND on it. it merely needs a C library. but when you build with USE=vanilla, it goes back to glibc building+installing the timezone-data, hence blocking the sep data files also makes sense.
So I have tested PDEPEND now, if I do like so: timezone-data: DEPEND="!<sys-libs/glibc-2.3.5" RDEPEND="sys-libs/glibc" glibc: PDEPEND+=" vanilla? ( !sys-libs/timezone-data ) !vanilla? ( sys-libs/timezone-data )" ./cross-emerge -1a glibc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-libs/glibc-2.19-r1 to /usr/x86_64-tm-linux-gnu/ USE="-debug -gd -hardened -multilib -nscd -profile (-selinux) -suid -systemtap -vanilla" [ebuild N ] sys-libs/timezone-data-2014f to /usr/x86_64-tm-linux-gnu/ USE="-nls -right_timezone" It works really nice! Would you consider adding this to timezone-data and glibc?
(In reply to Joakim Tjernlund from comment #10) > So I have tested PDEPEND now, if I do like so: > timezone-data: > DEPEND="!<sys-libs/glibc-2.3.5" > RDEPEND="sys-libs/glibc" > > glibc: > PDEPEND+=" > vanilla? ( !sys-libs/timezone-data ) > !vanilla? ( sys-libs/timezone-data )" > > ./cross-emerge -1a glibc > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ] sys-libs/glibc-2.19-r1 to /usr/x86_64-tm-linux-gnu/ > USE="-debug -gd -hardened -multilib -nscd -profile (-selinux) -suid > -systemtap -vanilla" > [ebuild N ] sys-libs/timezone-data-2014f to /usr/x86_64-tm-linux-gnu/ > USE="-nls -right_timezone" > > > It works really nice! > Would you consider adding this to timezone-data and glibc? I don't understand why I have to add RDEPEND="sys-libs/glibc" to timezone-data to make portage emerge timezone-data after glibc. Zac?
(In reply to Joakim Tjernlund from comment #11) > I don't understand why I have to add RDEPEND="sys-libs/glibc" to > timezone-data to make portage emerge timezone-data after glibc. > Zac? Since glibc-2.19-r1 has a timezone-data dependency in RDEPEND, emerge attempts to satisfy that dependency before it builds glibc-2.19-r1. Therefore, it builds timezone-data first.
(In reply to Zac Medico from comment #12) > (In reply to Joakim Tjernlund from comment #11) > > I don't understand why I have to add RDEPEND="sys-libs/glibc" to > > timezone-data to make portage emerge timezone-data after glibc. > > Zac? > > Since glibc-2.19-r1 has a timezone-data dependency in RDEPEND, emerge > attempts to satisfy that dependency before it builds glibc-2.19-r1. > Therefore, it builds timezone-data first. But I changed that RDEPEND to PDEPEND to prevent that. Still timezone-data is pulled in first.
(In reply to Joakim Tjernlund from comment #13) > But I changed that RDEPEND to PDEPEND to prevent that. Still timezone-data > is pulled in first. In the absence if circular dependencies, PDEPEND behaves much like RDEPEND. So, the changes that you suggested in comment #10 look reasonable to me.
i can live with it being in PDEPEND: http://sources.gentoo.org/sys-libs/glibc/glibc-2.20.ebuild?r1=1.2&r2=1.3 the latest glibc still builds & installs tzcode progs (not tzdata zoneinfo files), so the blocker is still necessary otherwise
(In reply to Zac Medico from comment #14) > (In reply to Joakim Tjernlund from comment #13) > > But I changed that RDEPEND to PDEPEND to prevent that. Still timezone-data > > is pulled in first. > > In the absence if circular dependencies, PDEPEND behaves much like RDEPEND. > So, the changes that you suggested in comment #10 look reasonable to me. What is then in timezone-data: DEPEND="!<sys-libs/glibc-2.3.5" if not a circular dep? BTW, is there a difference between DEPEND="!<sys-libs/glibc-2.3.5" and DEPEND=">=sys-libs/glibc-2.3.5" ?
(In reply to Joakim Tjernlund from comment #16) > (In reply to Zac Medico from comment #14) > > (In reply to Joakim Tjernlund from comment #13) > > > But I changed that RDEPEND to PDEPEND to prevent that. Still timezone-data > > > is pulled in first. > > > > In the absence if circular dependencies, PDEPEND behaves much like RDEPEND. > > So, the changes that you suggested in comment #10 look reasonable to me. > > What is then in timezone-data: > DEPEND="!<sys-libs/glibc-2.3.5" > if not a circular dep? Blockers don't create circular deps, they only specify conflicts. > BTW, is there a difference between > DEPEND="!<sys-libs/glibc-2.3.5" > and > DEPEND=">=sys-libs/glibc-2.3.5" > ? Yes, they are different because a blocker specifies what must NOT be installed, without saying anything about what MUST be installed. So, the blocker atom only serves to specify a state that would result in some sort of conflict.
(In reply to Zac Medico from comment #17) > (In reply to Joakim Tjernlund from comment #16) > > (In reply to Zac Medico from comment #14) > > > (In reply to Joakim Tjernlund from comment #13) > > > > But I changed that RDEPEND to PDEPEND to prevent that. Still timezone-data > > > > is pulled in first. > > > > > > In the absence if circular dependencies, PDEPEND behaves much like RDEPEND. > > > So, the changes that you suggested in comment #10 look reasonable to me. > > > > What is then in timezone-data: > > DEPEND="!<sys-libs/glibc-2.3.5" > > if not a circular dep? > > Blockers don't create circular deps, they only specify conflicts. > > > BTW, is there a difference between > > DEPEND="!<sys-libs/glibc-2.3.5" > > and > > DEPEND=">=sys-libs/glibc-2.3.5" > > ? > > Yes, they are different because a blocker specifies what must NOT be > installed, without saying anything about what MUST be installed. So, the > blocker atom only serves to specify a state that would result in some sort > of conflict. Right, of course. Do we still need that old blocker? 2.3.5 and older are long gone in the tree. That should have been RDEPEND and changing that to RDEPEND=">=sys-libs/glibc-2.3.5 makes the new PDEPEND in glibc work as intended. Having just DEPEND=">=sys-libs/glibc-2.3.5" has no effect on PDEPEND which I still find a bit odd. timezone-data should DEPEND on glibc too as it also has a build dep on glibc. I wonder if we can change all glibc ebuilds to PDEPEND and then just update timezone-data too?
(In reply to Joakim Tjernlund from comment #18) > Right, of course. Do we still need that old blocker? 2.3.5 and older are long > gone in the tree. I'll let the toolchain herd / Mike answer that. > That should have been RDEPEND and changing that to > RDEPEND=">=sys-libs/glibc-2.3.5 > makes the new PDEPEND in glibc work as intended. > Having just > DEPEND=">=sys-libs/glibc-2.3.5" > has no effect on PDEPEND which I still find a bit odd. When ROOT!=/ the DEPEND behavior depends heavily on your use of the --root-deps option (the cross-emerge wrapper probably uses it). > timezone-data should DEPEND on glibc too as it also > has a build dep on glibc. Yes, that seems reasonable to me. However, Mike has already expressed his own reasoning for the opposite (that you MUST use a sysroot or seed stage instead). > I wonder if we can change all glibc ebuilds to PDEPEND and then > just update timezone-data too? That's for the toolchain herd / Mike to decide.
(In reply to Zac Medico from comment #19) > (In reply to Joakim Tjernlund from comment #18) > > Right, of course. Do we still need that old blocker? 2.3.5 and older are long > > gone in the tree. > > I'll let the toolchain herd / Mike answer that. Sure > > > That should have been RDEPEND and changing that to > > RDEPEND=">=sys-libs/glibc-2.3.5 > > makes the new PDEPEND in glibc work as intended. > > Having just > > DEPEND=">=sys-libs/glibc-2.3.5" > > has no effect on PDEPEND which I still find a bit odd. > > When ROOT!=/ the DEPEND behavior depends heavily on your use of the > --root-deps option (the cross-emerge wrapper probably uses it). Right, I had forgot about just using --root-deps, doing that, a DEPEND=glibc will be enough to pull in timezone-data after glibc > > > timezone-data should DEPEND on glibc too as it also > > has a build dep on glibc. > > Yes, that seems reasonable to me. However, Mike has already expressed his > own reasoning for the opposite (that you MUST use a sysroot or seed stage > instead). Yes, but this is a step in the right direction to be able to drop that and it is backwards compatible(or so I think). > > > I wonder if we can change all glibc ebuilds to PDEPEND and then > > just update timezone-data too? > > That's for the toolchain herd / Mike to decide. Yes PS. Perhaps we this report now can loose the INVALID status?
the timezone-data blocker can be upgraded to looking at the vanilla flag instead http://sources.gentoo.org/sys-libs/timezone-data/timezone-data-2014g.ebuild?r1=1.1&r2=1.2
(In reply to SpanKY from comment #21) > the timezone-data blocker can be upgraded to looking at the vanilla flag > instead > > http://sources.gentoo.org/sys-libs/timezone-data/timezone-data-2014g. > ebuild?r1=1.1&r2=1.2 Thats better :) timezone-data do need an actual RDEPEND&DEPEND on glibc to make the PDEPEND in glibc work as intedend though. Can one have: RDEPEND="!sys-libs/glibc[vanilla(+)] sys-libs/glibc[vanilla(-)]" ? (unsure about the syntax) I think it is safe to change all glibc's to PDEPEND as it stands today. Then one can start moving timezone data over to xDEPEND on glibc
(In reply to Joakim Tjernlund from comment #22) > (In reply to SpanKY from comment #21) > > the timezone-data blocker can be upgraded to looking at the vanilla flag > > instead > > > > http://sources.gentoo.org/sys-libs/timezone-data/timezone-data-2014g. > > ebuild?r1=1.1&r2=1.2 > > Thats better :) > > timezone-data do need an actual RDEPEND&DEPEND on glibc to make > the PDEPEND in glibc work as intedend though. > Can one have: > RDEPEND="!sys-libs/glibc[vanilla(+)] > sys-libs/glibc[vanilla(-)]" > ? (unsure about the syntax) > > I think it is safe to change all glibc's to PDEPEND as it stands > today. Then one can start moving timezone data over to xDEPEND on glibc So I did some experiments, using sys-libs/glibc-2.20 and sys-libs/timezone-data-2014g Adding DEPEND="sys-libs/glibc[-vanilla]" RDEPEND="${DEPEND} !sys-libs/glibc[vanilla(+)]" to timezone-data appears to work but this was not an exhuastive test though. Not sure why !sys-libs/glibc[vanilla(+)] ?
(In reply to Joakim Tjernlund from comment #23) > (In reply to Joakim Tjernlund from comment #22) > > (In reply to SpanKY from comment #21) > > > the timezone-data blocker can be upgraded to looking at the vanilla flag > > > instead > > > > > > http://sources.gentoo.org/sys-libs/timezone-data/timezone-data-2014g. > > > ebuild?r1=1.1&r2=1.2 > > > > Thats better :) > > > > timezone-data do need an actual RDEPEND&DEPEND on glibc to make > > the PDEPEND in glibc work as intedend though. > > Can one have: > > RDEPEND="!sys-libs/glibc[vanilla(+)] > > sys-libs/glibc[vanilla(-)]" > > ? (unsure about the syntax) > > > > I think it is safe to change all glibc's to PDEPEND as it stands > > today. Then one can start moving timezone data over to xDEPEND on glibc > > So I did some experiments, using sys-libs/glibc-2.20 and > sys-libs/timezone-data-2014g > > Adding > DEPEND="sys-libs/glibc[-vanilla]" > RDEPEND="${DEPEND} !sys-libs/glibc[vanilla(+)]" > to timezone-data appears to work but this was not an exhuastive test though. > Not sure why !sys-libs/glibc[vanilla(+)] ? Thar should be DEPEND="virtual/libc" RDEPEND="${DEPEND} !sys-libs/glibc[vanilla(+)]"
i see no reason to change the timezone-data ebuild beyond what it has now
(In reply to SpanKY from comment #25) > i see no reason to change the timezone-data ebuild beyond what it has now As long there isn't a dependency on glibc, portage is allowed to merge any of glibc's PDEPENDs before glibc itself.
(In reply to Joakim Tjernlund from comment #26) sounds fine to me. i guess that means we're back to the point where relying on emerging glibc w/out glibc won't work
(In reply to SpanKY from comment #27) > (In reply to Joakim Tjernlund from comment #26) > > sounds fine to me. i guess that means we're back to the point where relying > on emerging glibc w/out glibc won't work Yes, we never left that state. I don't see why you are reluctant to add DEPEND/RDEPEND on glibc. To me there are only upsides: 1) timezone-data has as real DEPEND and RDEPEND on glibc 2) Adding that will ensure that glibc is built before timezone-data which will ensure timezone-data is built against the correct glibc 3) Also makes it possible to start with an empty SYSROOT(and ROOT?) I honestly do not see what might break?
(In reply to Joakim Tjernlund from comment #28) Gentoo, by design, does not list virtual/libc in packages. the # of packages in the tree that "need a C library" is so significantly high that adding such a dep is completely pointless. i don't find the fact that it helps out in the initial sysroot bootstrap case compelling enough here as we've never made the guarantee that will work.
(In reply to SpanKY from comment #29) > (In reply to Joakim Tjernlund from comment #28) > > Gentoo, by design, does not list virtual/libc in packages. the # of > packages in the tree that "need a C library" is so significantly high that > adding such a dep is completely pointless. Yes, I have noticed that. I didn't know that it wasn't allowed at all though. I figured one could add libc xDEPEND if there was a real need for it, as is the case here. > > i don't find the fact that it helps out in the initial sysroot bootstrap > case compelling enough here as we've never made the guarantee that will work. I know, but this is a step in the right direction, no need to make any guarantees yet.
