"xpath.c", line 11095: warning #2128-D: loop is not reachable from preceding codedo { ^hum ... strange, there is a goto next_node below which allows to get back in that do loop. So it is reachable from following code, not a very nice piece of code, but I would rather be prudent there.
Might be a mistake on the part of the compiler.
This one caught my eye:cc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./include -D_REENTRANT -g -Wp,-H30000 -c xmlschemastypes.c +Z -DPIC -o .libs/xmlschemastypes.lo "xmlschemastypes.c", line 1699: warning #2186-D: pointless comparison of unsigned integer with zeroif ((ret != 0) || (*cur != 0) || !VALID_DATETIME((&(dt->value.date)))) ^"xmlschemastypes.c", line 1699: warning #2186-D: pointless comparison of unsigned integer with zeroif ((ret != 0) || (*cur != 0) || !VALID_DATETIME((&(dt->value.date)))) ^The macros expands to quite a lot of code. Maybe running on the preprocessoroutput would help pinpoint what exactly is at stake there. I don't really understand the message too ... unless something like u < 0 I don't see thepoint being raised.
I'll see about getting just the pre-processed stuff.
This one brings-up another point:cc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./include -D_REENTRANT -g -Wp,-H30000 -c xmlmodule.c+Z -DPIC -o .libs/xmlmodule.lo "xmlmodule.c", line 284: warning #2167-D: argument of type "void **" is incompatible with parameterof type "shl_t *" rc = shl_findsym(&handle, name, TYPE_UNDEFINED, symbol); ^data vs. function pointers conversions.With PA2.0W (64-bit PA) and with IPF/ia64, (either 32 bit or 64) there is support for dlopen et al. In fact, the shl_findsym manpage has this to say:Future HP-UX environments may not support these routines and flags or may only support a subset of them. Instead, they will use the SVR4 dynamic loading API. Users are encouraged to migrate to the dl* family of dynamic linking routines. See the dlclose(3C), dlerror(3C), dlget(3C), dlgetname(3C), dlmodinfo(3C), dlopen(3C), and dlsym(3C) man pages for more information.for some reason while I'm typing the above I am getting a feeling of deja vu. anyway...Well I think we used that code explicitely because dlopen() wasn't available on old HP-UX systems...
Small matter of a check for dlopen in configure perhaps? Indeed old HP-UX systems didn't have dlopen. It arrived with "64-bit" (PA was in one sense 64-bit from day one - 32-bit spaceid and offsets) PA 2.0 support and is "the" mechanism on IA64.
"runtest.c", line 3859: warning #2177-D: function "thread_specific_data" was declared but never referencedthread_specific_data(void *private_data) ^not used on HP-UX but used for pthreads systems... let's ignore this
fair enough. the "not used on HP-UX but used for pthreads systems" seems strange - HP-UX has had basically proper pthreads since 11.0.
and then finally, an outright build error: creating parse2 No suffix list. sh: /usr/bin/xsltproc: not found. *** Error exit code 127 (ignored) sh: /usr/bin/xsltproc: not found. *** Error exit code 127 (ignored) sh: /usr/bin/xsltproc: not found. *** Error exit code 127 (ignored) sh: /usr/bin/xsltproc: not found. *** Error exit code 127 (ignored) Making all in example there is no xsltproc on the system:configure should have found this ... strange ...
I thought so - basically it found _something_ that led it to believe that xsltproc was present. I've been meaning to try on a system without the pre-compiled xml2 stuff on it but have been having trouble getting a contemporary compiler onto that system :(
though I must admit my ability to quickly parse shell stuff is pretty weak.and my ability to read generated configure code, is not much better...
I have fixed all okay'ed, and will commit as soon as I verify all regression tests still pass as expected.
sounds good. rick jones