compile samba-2.2.4 on Solaris 7

[Eric Boehm]

On Thu, May 30, 2002 at 10:55:45PM +1000, Andrew Bartlett wrote:
>>>>> "Tian"   == Tian-xiong Lu <tianl at agrecon.canberra.edu.au> writes:
>>>>> "Jerry"  == Gerald Carter <jerry at samba.org> writes:
>>>>> "Andrew" == Andrew Bartlett <abartlet at pcug.org.au> 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
boehm at nortelnetworks.com       \ /  No HTML or RTF in mail
                                X   No proprietary word-processing
Respect Open Standards         / \  files in mail