Heimdal prototype problem on OpenVMS
John E. Malmberg
wb8tyw at qsl.net
Sat Oct 22 19:01:52 GMT 2005
> "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
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
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
>>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
I will look for it on Monday when I get to where I have my build
In addition to working on porting SAMBA, in many cases I also have to
fix the UNIX/POSIX emulation environment and tools.
wb8tyw at qsl.net
Personal Opinion Only
More information about the samba-technical