I'm installing Gentoo on a system where only a minimal root is on a "mainstream" partition; the bulk of the installation is to be bind-mounted onto an HFS+ partition. This is something I've done before at least once with no issues at all, let alone issues on this level. I've just set up make.conf and synced my Portage tree. I want to do this right so I'm doing `emerge -DavuN world' before proceeding. The emerge is choking on libperl, though. If I manually go into its work directory and do some prodding I end up with interesting sequences of messages like: cp: cannot stat `makefile': No such file or directory cp: cannot create regular file `makefile': File exists Make generally refuses to detect the presence of a makefile and ls can't see it, but if I cat it or do `make -f Makefile' it works fine (to the point of detecting the makefile... it still barfs shortly after as soon as it tries to do a submake). I'm doing this from the 2006.1 minimal LiveCD on a PowerPC G3. A number of previous packages had built fine. I think it has something to do with the huge number of files in the work directory for that package. Reproducible: Always Steps to Reproduce: From the LiveCD, arrange for a /var on an HFS+ partition with an otherwise complete system, and do: emerge =sys-devel/libperl-5.8.8-r2 This can be done fairly early in the install process, immediately after syncing Portage and setting up make.conf. (If this works fine on a 2007.0 CD, then it could just be an issue with 2006.1; in which case I should upgrade like a good citizen.) Actual Results: Build chokes (complaining about a failure to make depends) Expected Results: Successful build. I had none of the USE flags for this package set (which is why it was being rebuilt in the first place). I'm working around it by adding an entry in package.use to avoid the need to rebuild.
Couple things, could you post your dmesg and lsmod please? And just to understand correctly when this is happening, you've already booted into your new kernel? or are you still under the livecd's kernel?
The install's being redone in a different way (pure reiserfs) by now, and I didn't save my dmesg, but as I recall there wasn't anything unusual in there. This is still with the LiveCD's kernel, I haven't rebooted into the system itself yet.
Are you still interested in helping out in diagnosing the problem then?
I'm swamped at the moment, but on the weekend I could try to make a simpler test case. Would that help?
yep -- if it's a consistent bug you should be able to reproduce it by creating a HFS+ partition and mounting it at /var/tmp/portage, then trying the emerge. It would also be helpful if you could provide a couple of pointers for how to format a HFS+ partition under linux, to save us the effort of looking it up when we come to attempting to reproduce it. thanks.
Here's how I tried to reproduce this: emerge diskdev_cmds dd if=/dev/zero of=hfs bs=1M count=200 mkfs.hfsplus hfs mount -o loop hfs /var/tmp/portage emerge libperl I get a problem too. It appears that Configure doesn't generate a Makefile, for some reason. When unmounting the HFS partition everything works fine again. Can anyone else confirm/deny this?
It isn't working here, either. It gets a short way in then dies, with the last interesting bit of the build log being this: If you compile perl5 on a different machine or from a different object directory, copy the Policy.sh file from this object directory to the new one before you run Configure -- this will help you with most of the policy defaults. make: *** No rule to make target `depend'. Stop. "ls" of the working directory doesn't show "Makefile" and neither does "find -name Makefile" (although it finds others in sub-dirs). Doing an "ls -l Makefile" shows a zero length file. Perhaps readdir is not returning the file, even though it exists. That would account for the behaviour I'm seeing. Does that match the symptoms you folks see?
Testing shows getdirents(2) doesn't return an entry for the file but stat(2) succeeds. One interesting looking thing: st_nlink == 0. Testing with "ls -l" shows the same thing: > ls -l /var/tmp/portage/sys-devel/libperl-5.8.8-r1/work/perl-5.8.8/Makefile -rw-r--r-- 0 duaneg duaneg 0 May 30 01:28 /var/tmp/portage/sys-devel/libperl-5.8.8-r1/work/perl-5.8.8/Makefile That shouldn't be possible, right?
Created attachment 120674 [details] checkdir.c Source code to test for presence of a file called "Makefile" using dirent and stat.
Bah, meant getdents not getdirents. The code is right, of course :)
Thanks for digging into this. Duane, could you please report this upstream at http://bugzilla.kernel.org including your analysis so far? We can still continue digging into this but right now it's best to get this bug report where it belongs (it's not a Gentoo-specific bug).
It looks like the bug may have already been reported. This sounds like what we are seeing: http://bugzilla.kernel.org/show_bug.cgi?id=7240 I can reproduce similar behaviour with the following: > touch a && stat A && rm a && stat A
I'm not sure how that is related, I don't see any discussion above of case sensitivity issues. At least from the description here, we're only talking Makefile, right?
I think this is what is happening: 1) The configure script creates a makefile 2) It stats both "Makefile" and "makefile" (amongst others), creating the dummy entry 3) It deletes the file 4) It does some other stuff that should generate another makefile 5) It looks for the makefile and finds the left-over zero-length one 6) It tries to use that to build with and dies I used strace to see what was going on with the process. That showed a pattern consistent with the above. The symptoms described in the bug are all consistent with it too, as far as I can tell, so that became my working hypothesis. Sorry, I should have explained this earlier. Anyway, I've just thought of another way to check this. I created a new case-sensitive HFS+ filesystem with: /sbin/mkfs.hfsplus -s /var/tmp/hfs-2 When I mounted that and retested the ebuild everything succeeded. It isn't definitive, but it seems the most likely explanation. I'm still looking into this, by the way, so any suggestions are welcome!
OK, looks like you're right. Perhaps you could just contribute your findings to the current upstream bug then.
I'll update upstream soon. I have a patch that I think fixes the HFS+ bug, but unfortunately the libperl ebuild still fails to compile. It appears to be creating "Makefile", deleting "makefile", then trying to use "Makefile". Naturally enough, this is problematic on a case-insensitive file system. :(
I've updated the upstream bug report with a patch that I believe fixes the problem. If the original reporter could test the patch I'd appreciate it. Keep in mind that libperl still won't build on a case-insensitive filesystem, though. Any feedback on the patch would also be appreciated. I'll submit it to the HFS+ maintainer and LKML once I get positive test reports on PPC.
