On Thu, May 30, 2002 at 10:55:45PM +1000, Andrew Bartlett wrote: >>>>> "Tian" == Tian-xiong Lu <[EMAIL PROTECTED]> writes: >>>>> "Jerry" == Gerald Carter <[EMAIL PROTECTED]> writes: >>>>> "Andrew" == Andrew Bartlett <[EMAIL PROTECTED]> writes:
Tian> Just tried compling samba-2.2.4 on a Solaris 7 box with two Tian> configure options: --with-libsmbclient --with-acl-support Tian> When compiling I got a warning message like this: In Tian> function "sys_readdir" lib/system.c 331 Warning: return from Tian> incompatible pointer type. Jerry> Am looking into it. Andrew> BTW, this is one of the things currently blocking us from Andrew> building on the Cray. (Now that just means that we will Andrew> find the next one, but anyway...) I've seen the following behavior on Solaris 8. 1. compiling 32-bit with Sun Workshop, configure checks for and finds readdir64... yes dirent64... yes 2. compiling 32-bit with Sun Workshop, configure checks for and finds readdir64... no dirent64... yes I believe that this is because the test program for readdir64 is incorrect. The normal test program is #line 5614 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char readdir64(); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char readdir64(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_readdir64) || defined (__stub___readdir64) choke me #else readdir64( ); #endif ; return 0; } This compiles okay as 32bit because it links with /usr/lib/libc.so.1, which contains readdir64. A 64-bit compile links with /usr/lib/sparcv9/libc.so.1 which doesn't contain readdir64 (since it isn't necessary). If we change the test program to: #line 5614 "configure" #include "confdefs.h" #include <assert.h> #include <sys/types.h> #include <dirent.h> /*char readdir64();*/ int main() { #if defined (__stub_readdir64) || defined (__stub___readdir64) choke me #else DIR *dirp; readdir64( dirp ); #endif ; return 0; } Then it builds and links okay. If you look at the pre-processed output, you can see why A 32-bit build generates #pragma redefine_extname readdir readdir64 extern DIR *opendir(const char *); extern struct dirent *readdir(DIR *); extern long telldir(DIR *); extern void seekdir(DIR *, long); extern void rewinddir(DIR *); extern int closedir(DIR *); extern struct dirent64 *readdir64(DIR *); int main() { DIR *dirp; readdir64( dirp ); ; return 0; } Note the "#pragma redefine_extname readdir readdir64" A 64-bit build generates #pragma redefine_extname readdir64 readdir extern DIR *opendir(const char *); extern struct dirent *readdir(DIR *); extern long telldir(DIR *); extern void seekdir(DIR *, long); extern void rewinddir(DIR *); extern int closedir(DIR *); extern struct dirent64 *readdir64(DIR *); int main() { DIR *dirp; readdir64( dirp ); ; return 0; } Note that "#pragma redefine_extname readdir64 readdir" is the reverse of the 32-bit build You would need to change configure.in but configure.in uses AC_CHECK_FUNC to generate the test program for readdir64. The generated program doesn't include the right include files or the right arguments. The check for dirent64 has a specific program rather than one generated by AC_CHECK_FUNC. -- Eric M. Boehm /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail