2.5.1pre3 - Bugs in configure script / config.h.in breaks build.
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
> >>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
> > 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