| Summary: | not all includes are converted to ph file in perl | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nahor <nahor.j+gentoo> |
| Component: | [OLD] Core system | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | woodchip |
| Priority: | High | ||
| Version: | 1.4_rc2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Nahor
2003-01-23 16:50:11 UTC
updating the perl builds with htph -r -l to take care of this. For the time being (unless you really want to re-install perl) please do the following: cd /usr/include; h2ph -r -l fixed with h2ph -r -l - if it's not, let me know, because that means h2ph is broken Started fine but ten failed on "/usr/include/asm/string-486.h" (from sys-kernel/linux-headers):
./asm/string-486.h -> ./asm/string-486.ph
Cannot parse:
"repnz; scasb
Also, I guess it's a typo in the post but there must be a period at the end of the h2ph command ("h2ph -r -l .")
typo was caught and fixed a few minutes later :) failing is actually "normal" accroding the the perl folks... I would not have worried much it did the other files but it stopped there. So apachelogserverstatus still fails to run for instance. When in doubt, brute force the sucker. (now in -r12)
cd /usr/include; find ./ -name "*.h" -exec h2ph -r -l {} \;
find ./ -name "*.h" | xargs -n 1 -P 2 h2ph -l It runs two processes in parallel instead of one. And the recursive parameter isn't necessary anymore. And also, to be a pain in the ass, it still doesn't fix the problem with stddef. With C application it works fine because, I guess, "/usr/include/linux" is in the default header path along with "/usr/include". While for perl application, only the equivalent of "/usr/include" is in it. So while perl could probably find "linux/stddef.h" but not "stddef.h". But I guess it should be another bug. |
