Summary: | app-arch/cpio-2.5.90 failed | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Roberto Griso <griso.roberto> |
Component: | Mac OSX | Assignee: | Gentoo for Mac OS X <ppc-macos> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugzilla |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 79788 | ||
Bug Blocks: | |||
Attachments: |
replaces isnumber by cpio_isnumber
fixes the linker error the modified ebuild |
Description
Roberto Griso
2004-12-19 04:53:12 UTC
Created attachment 47113 [details, diff]
replaces isnumber by cpio_isnumber
Created attachment 47114 [details, diff]
fixes the linker error
Created attachment 47115 [details, diff]
the modified ebuild
I had the same problem. The problem is that the function isnumber() and its two calls are replaced by a macro which is defined if neither _ANSI_SOURCE nor _POSIX_SOURCE are defined. IMO, the best thing to do is to replace the function name, because it's only used in this file. After you've fixed that you'll run into the next problem. The linker claims that the symbol _argp_program_version_hook is missing. This problem was already fixed. (cpio seems to have a copy of the file..) http://lists.nongnu.org/archive/html/bug-tar/2004-09/msg00023.html Finally the not gzipped manpage of gentoos cpio collides with the one from apples cpio. I don't know if it makes any sense to install the cpio package since apple provides it already (even if it seems to be a pretty old bsd cpio). But here are my patches and the slightly modified ebuild. err.. the ebuild needs "doman ${D}/usr/share/man/man1/cpio.1" instead of "doman cpio.1" (sorry) please try out cpio-2.6 in portage 2.6.0 doesn't need the linker (argp) patch anymore. It builds with the isnumber-patch applied in addition to the rili-big-files patch that's already in the ebuild. Fixed in CVS. Thanks. doman ${D}/usr/share/man/man1/cpio.1 as well as the isnumber patch are both in CVS. I left both without a `use ppc-macos &&` because the changes worked great on my x86 test box. has the isnumber patch been sent upstream ? also, wtf do you have that doman command ? it makes no sense on the patch being sent upstream: I believe this ML thread takes care of it, which is dated a few days ago. Should not be a problem in the next upstream release. http://lists.gnu.org/archive/html/bug-cpio/2005-01/msg00010.html on the doman line: from what I can see, doman also gzips the manpage, renaming the file to cpio.1.gz, which in turn avoids the collision problem on mac os x. Seeing as how some other manpages are also gzipped, I figured i'd leave it in global scope. Please let me know if this is wrong. doman is NOT for gzipping manfiles, it's for installing them that's the point of `prepman` and `prepallman`, see the ebuild(5) manpage regardless, you still dont need to do it because portage should auto compress the manpages before $D is merged to / (it does on my machine) ive punted the doman line, ive youve added that to other ebuilds, i'd suggest you do the same for those too existing file /usr/share/man/man1/cpio.1 is not owned by this package above is the output of emerge with the ebuild as stands after vapier's modification. vapier: could you perhaps modify the cpio-2.6 ebuild to gzip that man page? it would get rid of the above collision. as you said, doman isn't the preferred way to do this, so perhaps prepman, etc. are the way to go? or even just a raw gzip command (ugly)? up to you: whatever you'd like to use in order to get the job done. if you'd prefer I do it, please let me know what your preference is, and I can. you shouldnt have 'cpio.1' ... adding 'prepallman' would be the clean solution, but it shouldnt be needed i assume this is some OS X specific problem ? sorry I didn't make the problem clear: macos provides an older, outdated, bsd version of cpio (according to what I've heard and seen). The only file collision between macos' cpio and portage's cpio is the said manpage. would prepallman be allright to add to the ebuild, then? portage shouldnt have installed 'cpio.1', it should have installed 'cpio.1.gz': >>> Install cpio-2.5 into /var/tmp/portage/cpio-2.5/image/ category app-arch man: prepallstrip: <snip> >>> Merging app-arch/cpio-2.5 to / --- /usr/ --- /usr/share/ --- /usr/share/man/ --- /usr/share/man/man1/ >>> /usr/share/man/man1/cpio.1.gz Could you please check that this is the same behaviour with the 2.6 version? With 2.5, I get the gzipped manpage. With 2.6, I don't. err, sorry, here's the 2.6 output (but it's the same behavior): make[1]: Leaving directory `/var/tmp/portage/cpio-2.6/work/cpio-2.6' man: gzipping man page: cpio.1 info: gzipping GNU info page: cpio.info prepallstrip: <snip> >>> Merging app-arch/cpio-2.6 to / --- /usr/ --- /usr/share/ --- /usr/share/man/ --- /usr/share/man/man1/ >>> /usr/share/man/man1/cpio.1.gz man:
info:
gzipping GNU info page: cpio.info
prepallstrip:
strip: strip --strip-unneeded
...
>>> Completed installing cpio-2.6 into /var/tmp/portage/cpio-2.6/image/
* checking 22 files for package collisions
existing file /usr/share/man/man1/cpio.1 is not owned by this package
* spent 0.236688137054 seconds checking for file collisions
this is very odd, no?
what version of portage are you using ? portage guys: any ideas on this discrepancy in behavior ? I had same probelm with macos x 10.3.7 with latest image at main meta site, adding in the doman ${D}/usr/share/man/man1/cpio.1 line into my ebuild fixed it up just fine though. ok, this is a known issue (portage not gzipping manpages) file a new bug (if one isnt filed already) and talk to kito since he's up to-speed on the issue This package will not compile correctly until the portage bug is resolved. (bugs.g.o is MAKING me write a comment here) fixed in current portage release |