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

[John E. Malmberg]

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.


---

After this I ran into the ALLOCA mess. :-(

With Compaq C, the ALLOCA function is __ALLOCA(X),

and the prototype is:

void * __ALLOCA(size_t x);

But I do not have an alloca.h header file.

So I had to rework both SYSTEM.H and POPT.C to get things to compile, as
it was assuming the absence of alloca.h implied no alloca function, and
if the compiler was not GCC and not on AIX, that there was a specific
prototype for the alloca() function.

So it appears that POPT.C needs to use #ifdef HAVE_ALLOCA instead of
#ifdef HAVE_ALLOCA_H, which of course needs something to properly set it.

I do not know what the correct fix for SYSTEM.H, I am not sure that a
prototype should even be needed for a built in function.


 >
 >>I can do debugging or testing of the configure scripts.  So someone with
 >>a UNIX platform will need to verify what the fixes to the configure
 >>scripts need to be.
 >>
 >>
 >>OpenVMS does not execute configure scripts.  They are harder to port
 >>than the applications, and tend to generate incorrect results for the
 >>OpenVMS platform even after they are ported.
 >>
 >>Instead, an OpenVMS DCL procedure is used to read the CONFIG.H.IN file
 >>and uses it to search the system libraries to see what routines and
 >>header definitions are present.
 >>
 >
 >
 > 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.

The procedure is not perfect, but it is can handle building most of the
config.h file.  As a last step, the generate config.h file has a
#include "config_vms.h" to load in a hand edited file that does the fine
tuning.


I am now getting an almost clean compile, but I had to fix a lot of
"char *" definitions that either should have been "unsigned char *" or
"void *" in order for the build to complete.

I am still getting several diagnostics where the compiler is concerned
about being asked to put negative constants into unsigned variables.


Before I can start testing, I have to deal with the issue of OpenVMS not
currently having a fork() function.  I think that I can move one of the
processes to run as a "AST" thread, which has much less overhead than
the current implementation.  I do not yet know how much code I will have
to change to get that to work.

-John

wb8tyw at qsl.network
Personal Opinion Only