2.5.1pre3 - Bugs in configure script / config.h.in breaks build.

Dave Dykstra dwd at bell-labs.com
Fri Jan 4 02:44:49 EST 2002

On Wed, Jan 02, 2002 at 11:50:45PM -0600, John E. Malmberg wrote:
> Dave Dykstra wrote:
>  > On Tue, Jan 01, 2002 at 06:45:59PM -0600, John Malmberg wrote:
>  >
>  >>Compaq C 6.5
>  >>OpenVMS Alpha 7.3
>  >>
>  > ...
>  >
>  >>A second issue, is the line:
>  >>
>  >>#undef socklen_t
>  >>
>  >>It is not in the standard format for the other lines in the configure
>  >>script.
>  >>
>  >>It would be helpful for it to be:
>  >>
>  >>#undef HAVE_SOCKLEN_T
>  >>
>  >>And then somewhere else, where the defintion is used, or in rsync.h
>  >>
>  >>#ifndef HAVE_SOCKLEN_T
>  >>typedef socklen_t size_t
>  >>#endif
>  >>
>  >
>  >
>  > That's not enough because it needs to figure out what value to use to
>  > define socklen_t; the current logic in aclocal.m4 tries
>  >     int size_t unsigned long "unsigned long"
>  > until it gets one to compile.
> Depending on the compile options selected or defaulted, and if standard
> headers are selected or not, a C compiler may not produce the expected
> results from one of the test programs in a configure script.
> One of the main reasons that the configure scripts do not work well off
> of a UNIX platform is that some UNIX library functions have multiple
> implementations for mapping to native operating system features.
> There are a number of cases where a programmer needs to select at
> compile time which behavior is correct.  Or if the compiler is to
> conform to new standard or library routine behavior change or to be
> backwards compatable.
> So even if I were to obtain a UNIX compatable shell for OpenVMS like
> GNV, the configure results would likely still be misleading.
> For an autoconfigure to be truly cross platform, it must be table
> driven, so that a family of similar Operating systems like the *NIX
> could share common scripts, but non-*NIX operating systems can supply
> scripts that are specific to them.

You seem to have misunderstood me; I wasn't talking about getting configure
to work on OpenVMS, only to get it to work on *NIX operating systems while
making it friendly for you to scan config.h.in.   I'm saying we can't just
use "typedef socklen_t size_t" because the value is not always size_t and
has to be calculated on *NIX systems and presumably set in some other #define.
We could just make up a name for that other #define, but does that help you?
Is there some standard format that would make it easy for your DCL procedure
to recognize it?

> After this I ran into the ALLOCA mess. :-(
>  > Is there some other syntax that the procedure accepts to allow passing a
>  > value through?
> The procedure is basically looks for symbols in the libraries.  Sort of
> like using grep to look things up in the header files instead of doing the
> test files.
> If it does not get a match from reading the config.h.in file, it then
> scans the configure. file to see if there is a simple assignment in it like:
> symbol = n
> If so, it then does a #define symbol n
> The DCL procedure has some special cases coded into it.  I can place an
> additional one for socklen_t, now that I know about it.  But it is still
> better to use the HAVE_SOCKLEN_T indicate if a substitution is needed.
> Basically I will put in a special case that if it sees
>      "#undef HAVE_SOCKLEN_T", and it does not find it in the standard
> header files, it will insert a "#define HAVE_SOCKLEN_T 1" and then the
> needed typedef for socklen_t.

Oh, ok, that could work.  When you've got everything finished submit a


- Dave Dykstra

More information about the rsync mailing list