Summary: | Building libperl on an hfsplus filesystem gives screwy disappearing-reappearing makefiles | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Solra Bizna <sbizna> |
Component: | [OLD] Development | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | duaneg |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=7240 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | checkdir.c |
Description
Solra Bizna
2007-05-13 09:03:51 UTC
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. |