Heimdal prototype problem on OpenVMS

[John E. Malmberg]

Love wrote:
> "John E. Malmberg" <wb8tyw at qsl.net> writes:
> 
>>>Add the missing autoconf tests ? The all compat functions are wrapped in
>>>#ifndef statements, and they need autoconftest to not be defined.
>>
>>Configure is currently barely on speaking terms with me.  I have
>>already notice that it's standard method of testing is with out the
>>standard header modules present.
> 
> For wierd platforms, ie non unix :), like probably easier to have a static
> config.h that gets copied to the right place when building.

It was up until the build procedures to create the config.h and makefile 
got complicated enough that I needed to actually run the configure 
script.  Before then it was much easier to run a native script on 
config.h.in and generate the correct results.

But in the past, I have noticed that the issues like I am seeing 
configure get wrong have also shown up in UNIX and other systems that 
are trying to maintain SAMBA ports.

>>Is there an interest in fixing Configure so that it actually is doing
>>the tests in a way that are more likely to not have false failures?
>  
> So the problem with configure is no longer that its entenched with sh but
> rather something else ?

The problem is that configure is testing the fallback behavior of the C 
library, not the behavior of the C library in a standard compliant C 
program.

As such, for any platform that by default maintains backwards 
compatibility with older version of source code or binary code, or 
behaviors that existed before ANSI and X/Open published standards, 
configure is highly likely to produce wrong answers.

On OpenVMS, if the standard header files are not present in a C module, 
the compiler directs the linker to bring in routines that are compatible 
with the oldest implementation of the function.

I would not be surprised if this is not an issue on many UNIX systems, 
especially the commercial ones.  But because the output of configure is 
trusted, it has not been noticed.

But because I can not trust the output of configure, and I have to pay 
attention to what it is testing, I will be noticing many of these cases.

To make sure that Configure produces the correct answers, it should be 
testing in a mode with ANSI/X-Open compliant headers first and only go 
looking for the alternate possibilities if the standard header compliant 
tests fail.

As it is, it appears that Configure almost never checks to see if an 
ANSI/X-Open compliant test works unless the test that is not guaranteed 
to produce useful results on all platforms succeeds.

While watching Configure run on SAMBA and several other GNU projects, I 
notice that it is first verifying that a header file works, and then 
checking for it's existence.  If it works, it must exist, so why is this 
additional test even being run?  All that is doing is increasing the 
time to run the Configure script by up to 30%.

If Configure were to do the ANSI/X-Open test first, not only would it 
produce more accurate answers, it would probably run faster.  It may be 
possible to skip up to 50% of the tests it is doing.

In my case, I can either try to fix the Configure scripts to do what 
they should be doing, or use back doors in the UNIX/POSIX emulation to 
game the environment.

The first option probably requires some help from someone that knows 
shell programming better than I do.  (easy to find :-).

The second only helps me, but I must constantly adjust my tweaks as new 
Configure tests are added that follow the existing model.

>>>Or simply remove them from roken.h if they are not used by the
>>>kerberos/gssapi library.
>>
>>Because the current build seems to create some source code on the fly,
>>and I have yet to get a build done, I do not know if they are needed.
>>A simple search of the source code seems to indicate that they are not used.
>  
> Check config.h.in, it should contain enough clue if the define is needed or
> not.

I will look for it on Monday when I get to where I have my build 
environment.

In addition to working on porting SAMBA, in many cases I also have to 
fix the UNIX/POSIX emulation environment and tools.

-John
wb8tyw at qsl.net
Personal Opinion Only