Summary: | xfsprogs-2.6.25 ebuild fails on uclibc/embedded. (mincore+fadvise missing) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Axel Dyks <XL> |
Component: | New packages | Assignee: | Embedded Gentoo Team <embedded> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | geekypenguin, natanael.copa |
Priority: | High | ||
Version: | 2004.3 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
The "configure/aclocal.m4-patch" and a modified ebuild that applies the patch
Test-Case for fadvise on glibc/uclibc platforms 2.6.25-uclibc-fadvise.patch |
Description
Axel Dyks
2004-12-08 17:33:43 UTC
Created attachment 45579 [details]
The "configure/aclocal.m4-patch" and a modified ebuild that applies the patch
In the ebuild you have. ------------------------------------------------------------- # "mincore" and "fadvise" are not available when building # with "uclibc", although "configure" detects them. use uclibc && \ epatch ${FILESDIR}/${PV}-uclibc-mincore-fadvise.patch ------------------------------------------------------------- We try to never conditionally patch. Is something like adding "ifdef __UCLIBC__" to "io/Makefile" and setting __UCLIBC__ (on "use uclibc") ok for you? If so, I'd change the patch and the ebuild... Don't know very much of your (internal) rules for creating ebuilds, so please be forgiving. :-) -Axel I can add mincore() to uClibc itself. As for the posix_fadvise/posix_fadvise64 part I think xfsprogs is probably handling it wrong. It should only be used when __USE_XOPEN2K is defined. see /usr/include/fcntl.h Created attachment 46598 [details]
Test-Case for fadvise on glibc/uclibc platforms
Hmm... I'm not sure, if I 've correctly understood.
I've found your discussion on "ibot.rikers.org/uclibc" about the missing
mincore() function and that somebody said "should be trivial to implement it in
uClibc". Don't know if it's really that simple but building xfsprogs on
uclibc without needing a patch would be great. :-)
I can't follow your statement on "fadvise/fadvise64".
After reading "fcntl.h" and some references about posix-defined
functions I wrote the small test-case that I have attached.
Compilation is successfull on uclibc- and glibc-platforms.
Linking is successfull on glibc but FAILS on uclibc.
Axel
I 've just inspected <fcntl.h> from my "original" uclibc-buildroot and found the following... ----------------------------------------------------------------------------- #if 0 /* FIXME -- uClibc should probably implement these... */ #ifdef __USE_XOPEN2K /* Advice the system about the expected behaviour of the application with respect to the file associated with FD. */ # ifndef __USE_FILE_OFFSET64 extern int posix_fadvise (int __fd, __off_t __offset, size_t __len, int __advise) __THROW; # else # ifdef __REDIRECT extern int __REDIRECT (posix_fadvise, (int __fd, __off64_t __offset, size_t __len, int __advise) __THROW, posix_fadvise64); # else # define posix_fadvise posix_fadvise64 # endif # endif # ifdef __USE_LARGEFILE64 extern int posix_fadvise64 (int __fd, __off64_t __offset, size_t __len, int __advise) __THROW; # endif ... ----------------------------------------------------------------------------- I think the actual problem is that some header files of gentoo-embedded do not correspond with the underlying "uclibc", i. e. an external function is declared although it is not implemented. For xfsprogs' (and other's?) "configure" only tries to _compile_ test code containing the functions in question (fadvise, mincore, ...) it does not recognize that the implementation is missing from the library. Axel solar fixed this by implementing the needed functions in uclibc ;) SpanKY: only 50% fixed. posix_fadvise64() does not exist. what's the status of that function ? do we just need a syscall wrapper in uclibc ? And what about "#if 0 ..." in "fcntl.h"? At least until those functions (fadvise, ...) have been implemented. --Axel ive implemented the two functions in upsteam uclibc cvs, but i need to implement _syscall6() for i386 ... then i can cut a patch from cvs and this should be resolved for everyone in the mean time is xfsprogs not building for people? If so shall we disable the one module for now so people can build it again? I think we should disable it as long as it isnt gonna cause problems with the package, from what I have read doesnt appear it will!! Created attachment 49828 [details, diff]
2.6.25-uclibc-fadvise.patch
slimmed down aclocal patch
last patch is in cvs.. Thanks! (also for providing mincore in uclibc) --Axel Resolve bug as FIXED. Spanky will add syscall6 when he is in the mood and we will revisit xfsprogs another day. *** Bug 117559 has been marked as a duplicate of this bug. *** |