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

Jeremy Allison jeremy at netcom.com
Fri Dec 18 17:11:25 GMT 1998

David Collier-Brown wrote:

>       Found it, several layers deep: configure is 
>       trying to find out the cpp to use, sees a non- 
>       empty conftest.out file from cc -E, and concludes 
>       that this is the wrong cpp. Alas, comptest.out 
>       contains 

Unfortunately this would mean changing GNU
autoconf itself I think (it's hard to check
at the moment as I'm actually not in at work
today - I'm taking a 'personal day' to try
and finish all my Christmas shopping :-( ).

We've been trying to avoid having to maintain
our own version of autoconf as it's a massive
pain. Maybe Andrew can correct me on this (that
it needs autoconf changes) - I'll only be able 
to look at this fully later.

Does Sun CC really *have* to put all that
crap in an output file when invoked with
cc -E ? Isn't there some way to turn it off ?

> and, having done  that, consider
> 2) reordering the statvfs tests to look for statvfs,
> then statvfs64, **IFF this will not break other
> vendors' interim large-files logic**. 

I don't think it would - but I'll have to
check the logic of the disk_free module.
The way I've done it in the lib/system.c 
wrappers is to always use the 64-bit explicit
interface if it's found. The way all other
vendors with large file support are set up
is to completely hide the 64 bit explicit
calls if you set the CPP flags to request
implicit (ie. 64 bit off_t size). Is there
*any* way for Solaris to do this ? Making
that change should just cause statvfs to
be found (in implicit 64 bit mode) and
statvfs64 not to be found. Using explicit
64 bit mode should reverse this (ie. statvfs
not to be found, and statvfs64 to be found).
If that doesn't happen then Solaris must have
some breakage in its include files.

> A quick test shows it will then find statvfs64... and fail to find 
> any locking: this looks like a nasty problem in configure: we've
> just exposed some untested code paths.

I don't think so. The locking tests work
on all other platforms Samba compiles on.

Having the locking tests fail is usually
a sign of previous breakage in the configure
process (for example the locking tests failed
on HPUX 10.0 until I fixed the shadow include
problem - not something you'd think would
have an effect :-).

As you have the official Sun 'reference'
Solaris 2.6 I'm hoping you can give me a
patch to configure.in (*not* autoconf :-)
that will fix this for Solaris. It wouldn't
be good to have to tell all Solaris/Samba 2.0
users to have to use gcc as Sun's compiler
set is broken :-) :-).

I'm going to CC: Andy Bowers at the Sun UK
office on this message as I know he has some
experience in this area (hi Andy).



More information about the samba-technical mailing list