I'd say so, too. The ushort etc. problems indicate that as well. All of
these indicate that some simple preprocessing and compilations are failing
that shouldn't, and I'd bet a lot that they are all related and could
indicate other configure problems that are waiting to bite.
I've debugged a *lot* of these, so permit me to give a little advice. I'd
edit the configure script, and find where the bad tests are. For the u
types, there are really two tests: one looking for the string utype in a
preprocessor output and, if that fails, one trying to compile a little
program that includes a utype definition. After configure, there will only
be a definition in dxconfig.h if both these tests are failing. I'd edit
configure, find where its looking for utypeand echo out a bunch of variable
values:
echo $ac_ext will tell you whether its trying C or C++
echo $ac_cpp will give you the preprocessor statement it tries
echo $ac_compile will give you the compile statement it tries
echo $CC
echo $CPP
echo $CXX
echo $CXXCPP
echo $CFLAGS
echo $CPPFLAGS
and add an exit to quit the configure script. Then edit the cache file to
remove ac_cv_type_ulong (for example) and run the configure script to get
the values of those variables.
Theres a conditional that selects either of two little files to preprocess
depending on whether windows.h is found - which it shouldn't be, since ARCH
is not intelnt. So it'll try the preprocessing statement on:
#include "confdefs.h"
#include <sys/types.h>
#if STDC_HEADERS
#include <stdlib.h>
#include <stddef.h>
#endif
confdefs.h is a list of definitions found in earlier tests. So run the cpp
statement. Either it will simply failing, so no output to stdout is
produced,
or utype just isn't there, in which case thats the problem and stderr will
tell you a lot about whats going on.
If the preprocessor didn't fail and utype just isn't in the output, then
the compilation test kicks in. It tries the compile statement on:
#include "confdefs.h"
int main() {
ulong foo;
; return 0; }
and thats failing; again stderr will tell you why.
Greg
Richard Gillilan <[EMAIL PROTECTED]>@opendx.watson.ibm.com on
06/19/2000 08:03:10 AM
Please respond to [email protected]
Sent by: [EMAIL PROTECTED]
To: [email protected]
cc:
Subject: Re: [opendx-dev] IRIX: libdx client.c sys/socket.h AF_INET etc.
socket.h is in /usr/include/sys on my machine (SGI Octane dual R10K running
IRIX
6.5.5m).
I just did the following:
1. cvs update
2. rm config.cache
3. make distclean (I now see this also removes config.cache)
4. CVSMake
some warnings about AC_TRY_RUN
5. ./configure
6. edit dx/include/dxconfig.h to remove ushort, ulong and uint defs
7. make
Still, same problems. It's not finding socket.h
Sounds like more evidence that configure script is failing on my system.
I'll be trying to debug this today.
Richard
