[Fwd: [Patch] Configure broken for Solaris 2.6 (PR#12014)]

[David Collier-Brown]

Daniel Eischen wrote:
> Yes, we are using gcc.  Hmm, but now that you mention it, the
> gcc we were using was built for Solaris 2.5, not Solaris 2.6.
> And the Solaris 2.6 system is also patched a recent Sun
> recommended 2.6 patch cluster thingy.
> 
> Subsequent to reporting this problem, I have rebuilt GCC
> (2.8.1) for Solaris 2.6.
> 
> Looking at the Sun include files, it still looks like we
> should be using LARGEFILE64_x instead of LARGEFILE_x.

	Righto: I think I see what's happening...
	
	Samba explicitly calls statvfs64() function, and
	the sun implementation triggered by 
	-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
	only makes statvfs() visible, using the 64-bit
	sizes of the various variables.

	I **think** this means we should check for
	a native statvfs with -D_LARGEFILE_SOURCE
	and -D_FILE_OFFSET_BITS=64, and see if it
	exists. 
	
	[explanation:
	_LARGEFILE_SOURCE really means "migrate all
	32-bit calls to 64-bit,. without changing the
	function names or data structure names, just
	as if you were running on a machine with
	longs and pointers of 64 bits"

	
	_LARGEFILE64_SOURCE means "provide xxx64() 
	functions and structs, so you can mix standard
	32-bit calls with 64-bit calls".

	The latter is, in my considered (ie, not humble at all)
	opinion, a usefull kludge, suitable for a quick
	hack around a problem.  Not for real code!]

	I loked at my 2.7 system, it ends with a sucessful
	compile-check of statfvs:
----
configure:7292: checking how to get filesystem space usage
configure:7299: checking statvfs64 function (SVR4)
configure:7351: checking statvfs function (SVR4)
configure:7648: cc -o conftest -O   conftest.c -lsocket -lnsl -ldl 
-lpam 1>&5
#cc:/export/home/local-davecb/projects/personal/samba/samba/source:-o
conftest -
O conftest.c -lsocket -lnsl -ldl -lpam
/opcom/on998-tools/SUNWspro/SC4.2/bin/../SC4.2/bin/acomp -i conftest.c
-o /tmp/a
compAAAngBYF_ -r /tmp/acompBAA0V07OO -H -Qy -D__SunOS_5_7
-D__SUNPRO_C=0x420 -D_
_SVR4 -D__unix -D__sun -D__sparc -D__BUILTIN_VA_ARG_INCR -Xa -Dunix
-Dsun -Dspar
c -D__RESTRICT -I/opcom/on998-tools/SUNWspro/SC4.2/SC4.2/include/cc -O2
"-g/opco
m/on998-tools/SUNWspro/SC4.2/bin/../SC4.2/bin/cc -H -xtime -O -lsocket
-lnsl -ld
l -lpam -c "
./confdefs.h
././tests/summary.c
        /usr/include/stdio.h
                /usr/include/sys/feature_tests.h
                        /usr/include/sys/isa_defs.h
                /usr/include/sys/va_list.h
                /usr/include/stdio_tag.h
                /usr/include/stdio_impl.h
                        /usr/include/sys/isa_defs.h
acomp           real    0.0     user    0.0     sys     0.0
---
Note that none of the -D options are set: this machine is
64-bit already, and sysconf knows that.

Next I configure on a 2.6 32-bit system with Sun cc:
it shudders to a halt after...
----
checking how to get filesystem space usage
checking statvfs64 function (SVR4)... no
checking statvfs function (SVR4)... no
checking for 3-argument statfs function (DEC OSF/1)... no
checking for two-argument statfs with statfs.bsize member (AIX,
4.3BSD)... no
checking for four-argument statfs (AIX-3.2.5, SVR3)... no
checking for two-argument statfs with statfs.fsize member (4.4BSD and
NetBSD)... no
checking for two-argument statfs with struct fs_data (Ultrix)... no
checking configure summary
configure: error: summary failure. Aborting config
---

In the config.log, this was from the compile line
---
configure:9092: cc -o conftest -O  -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64  conftest.c -lsec -lsocket -lnsl  -lpam 1>&5
---

I think the previous compile (of statvf()) should have
succeeded.  I'll look at it next and report.

--dave