Make/Linking fails in subdir "./io" on unresolved symbols "mincore" (mincore.o) and "posix_fadvise64" (fadvise.o). Availability of these (system) functions is checked by "./configure", but not detected correctly (test-compile works, linking would fail). I will attach a patch for "./configure" and "aclocal.m4" (in case someone wants to run autoconf). Don't know, if it's possible to fix this upstream (http://oss.sgi.com/bugzilla/, http://www.uclibc.org), but I will try my very best. ByTheWay: "xfsprogs" are obviously meant to run _also_ on systems without "mincore"/"fadvise". Otherwise "./configure" would terminate with an error. -Axel
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. ***