The configure script adds 'df' to optional_bin_progs as it says "only if there's a point to it" hence it may not always be built. However, coreutils-7.5-r1.ebuild lists 'df' as a member of $fhs and uses 'mv' to copy this set of binaries. In the event that 'df' is not present (not built) this cause the emerge to fail: ... mv: cannot stat `df': No such file or directory * ERROR: sys-apps/coreutils-7.5-r1 failed: * could not move fhs bins ... Reproducible: Always Steps to Reproduce: 1.emerge sys-apps/coreutils-7.5-r1 on a system without libgtop where configure decides not to build 'df' 2. 3. Actual Results: emerge fails because 'df' is not built Expected Results: emerge succeed without 'df' I was crosscompiling but looking at the ebuild I don't think that is relevant maybe omit 'df' from the set $fhs in the ebuild?
Could you start with attaching full build log and telling what does libgtop have to do with a failing coreutils emerge ?
Created attachment 225423 [details] failed coreutils build.log
(In reply to comment #1) > Could you start with attaching full build log > and telling what does libgtop have to do with a failing > coreutils emerge ? > build.log attached, the configure script contains this ... # Build df only if there's a point to it. if test $gl_cv_list_mounted_fs = yes && test $gl_cv_fs_space = yes; then { if test -z "$optional_bin_progs"; then optional_bin_progs=df else optional_bin_progs="$optional_bin_progs df" fi } fi ... after running ./configure config.log contains gl_cv_list_mounted_fs=yes gl_cv_fs_space=no hence 'df' is not added to optional_bin_progs hence 'df' will not be built by the Makefile I mentioned libgtop because src/df.c includes fsusage.h which is provided by libgtop and if this is not installed then df.c would not compile anyway,
(In reply to comment #3) ... > > I mentioned libgtop because src/df.c includes fsusage.h > which is provided by libgtop and if this is not > installed then df.c would not compile anyway, > Actually this is wrong... there happens to be a different 'fsusage.h' in libgtop, the one used by df.c is, of course, the one in coreutils... The "bug" as I see it is the fact that 'df' is only conditionally present but the build file unconditionally tries to move it, hence in any case where 'df' is not compiled the emerge will fail. A fix would be to move it iff it exists and silently continue if it does not.
The next step would be attaching config.log.
Created attachment 225491 [details] config.log for coreutils here is config.log
Add 'emerge --info'. Something seems to be wrong here: check for 'two-argument statfs with statfs.bsize' should succeed (it does here on glibc x86). However, for some reason, config.log lacks any info why it fails.
Oops, I've reread your report - you were cross-compiling and that check uses AC_RUN_IFELSE - quite obviously something that can't succeed in such circumstances.
(In reply to comment #8) > Oops, I've reread your report - you were cross-compiling > and that check uses AC_RUN_IFELSE - quite obviously > something that can't succeed in such circumstances. > That is correct. However all of the coreutils binaries with the exception of 'df' are correctly crosscompiled and can be moved into /bin and used on the target. The only problem is that the ebuild fails because it tries to move a file that is intentionally missing. Hence it is the ebuild that is wrong. If it is changed so it does not look for 'df' then all is well. In order to work in normal and crosscompiling cases it should move the binaries listed in $fhs without 'df' and only try to move 'df' if it exists. 'emerge --info' is not useful because it shows host not target info I think you want 'xmerge --info' but I attached both
Created attachment 225505 [details] emerge --info
Created attachment 225507 [details] xmerge --info
You've missed the point. It was: as those checks are failing, df is not built; if one of them (the correct one) would succeed, df would be built and there would be no problem. The only reason why 'df' is not built, is that you're cross-compiling.
(In reply to comment #12) > You've missed the point. > It was: as those checks are failing, df is not built; > if one of them (the correct one) would succeed, df would > be built and there would be no problem. > The only reason why 'df' is not built, is that you're cross-compiling. > Well I understand that, are you saying that coreutils cannot be crosscompiled using a Gentoo ebuild? How would you suggest that I solve the problem?
in the future, you need to state when you are doing non-standard things (like cross-compiling) so people dont waste time trying to diagnosis the standard probably fixed now: http://sources.gentoo.org/sys-apps/coreutils/coreutils-8.4.ebuild?r1=1.2&r2=1.3
(In reply to comment #14) > in the future, you need to state when you are doing non-standard things (like > cross-compiling) so people dont waste time trying to diagnosis the standard > > probably fixed now: > http://sources.gentoo.org/sys-apps/coreutils/coreutils-8.4.ebuild?r1=1.2&r2=1.3 > Sorry for confusion but my initial description said "I was crosscompiling..." I tried your fix and there is a small problem, setting fu_cv_sys_stat_statfs2_bsize=yes in the environment of econf DOES solve the problem but your patch sets it a couple of lines before 'econf' is invoked and when I do that it is not seen by 'configure' Is 'econf' perhaps run in its own shell? that is to say 'fu_cv_sys_stat_statfs2_bsize=yes econf' works but using separate lines 'fu_cv_sys_stat_statfs2_bsize=yes ... econf' does not
while you're right, if you're doing something weird like this, it really needs to be in the first sentence or two, not in the "expected results" that gets glazed over. the variable needs to be exported: http://sources.gentoo.org/sys-apps/coreutils/coreutils-8.4.ebuild?r1=1.3&r2=1.4
(In reply to comment #16) > while you're right, if you're doing something weird like this, it really needs > to be in the first sentence or two, not in the "expected results" that gets > glazed over. > > the variable needs to be exported: > http://sources.gentoo.org/sys-apps/coreutils/coreutils-8.4.ebuild?r1=1.3&r2=1.4 > Thanks for all the help, I can confirm that /sys-apps/coreutils/coreutils-8.4.ebuild rev 1.5 successfully cross emerges between powerpc64 and powerpc. and 'df' is built and installed (have not yet tested target binaries)
