Bugzilla Bug 73855

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 an attachment (id=45579) [edit]
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 an attachment (id=46598) [edit]
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 an attachment (id=49828) [edit]
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. ***