don@zippy.eecs.umich.edu (Don Winsor) (01/03/90)
I have found a couple of minor problems when configuring perl
release 3.0 patchlevel 8 on systems running Ultrix. I have verified
these on a Vax-3600 running Ultrix 3.0 and on a DECstation-3100
running Ultrix 3.1, using the Ultrix C compiler on both systems.
The first problem is that Ultrix has a <utime.h> header file, but it
isn't what perl expects; it doesn't define the "acusec" or "modusec"
in it's utimbuf structure. The result is that config.sh ends up with:
i_utime='define'
when it really should contain:
i_utime='undef'
The workaround is easy; when running Configure, edit config.sh
when asked and make the change manually. I'll leave it to
Larry to choose the best permanent fix to Configure; perhaps
if it finds /usr/include/utime.h it should examine it for
the necessary symbols before defining i_utime.
The second problem only applies to DEC machines with the
MIPS CPU, such as the DECstation-3100. The interesting
structure declarations in <signal.h> are hidden inside
the following:
#if defined(vax) || (defined(mips) && defined(LANGUAGE_C))
Configure runs <signal.h> through the C preprocessor before
searching for the declarations. Since /lib/cpp doesn't
define LANGUAGE_C by default (normally, cc will define it
when calling cpp, but Configure invokes /lib/cpp directly on
these systems), the #if is not included, and the declarations
are never found. The result is that Configure sets
d_voidsig='undef'
when it should be
d_voidsig='define'
Once again, an easy workaround is to manually edit config.sh
appropriately. It is not clear to me what the cleanest fix
for Configure would be. Having it use "cc -E" instead of
"/lib/cpp" is one possibility, but that is a bit messy since
"cc -E" can't read standard input, so it will be necessary to
use a temporary file as it seems to currently do with gcc.
Another possibility might be to stick a "-DLANGUAGE_C" on
the invocation of "/lib/cpp" that looks through <signal.h>.
Don Winsor
Department of Electrical Engineering and Computer Science
University of Michigan, Ann Arbor
don@dip.eecs.umich.eduevans@testmax.ZK3.DEC.COM (Marc Evans Ultrix Q/A) (01/03/90)
I sent Larry a patch for the VOIDSIGNAL problem last week. The problem
in the Configure is actually a bit further reaching then you might think.
On MIPS based hosts (not vaxes!) under ULTRIX, /bin/cc sets the environment
variable LANGUAGE_C when the file being processed is determined to be C
source code (it looks for the '.c' on the end of the name). This allows for
assembly code to be processed by the same front end, as well as the include
files to be used by both C and the assembler.
The approach that I took in modifing Configure was to modify the test header
text to include a '#ifdef LANGUAGE_C', and then modify each invocation of the
$cppstdin to have the argument '-DLANGUAGE_C'. The problem is that I do not
know how portable this construct will be (eg. do all *ix /bin/cc parse the
'-D' syntax?). I guess that Larry can figure this out as needed.
The bottom line of why I am sending this message is because there are other
include files (and a lot more will be comming in the next major release of
ULTRIX) that will contain this construct, so we better get used to handling
it if that is possible (maybe an ULTRIX detector in configure would be
useful?).
- Marc Evans
==========================================================================
Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)893-8481
Unix/X-window Software Contractor | 3 Koper Ln, Pelham, NH 03076
==========================================================================