Re: [xml] misc warnings compiling libxml2-2.6.22 (cvs snapshot dloaded 2005/12/09) with HP aC++/ANSI C B3910B A.06.05 [Jul 25 2005]



"xpath.c", line 11095: warning #2128-D: loop is not reachable from preceding code
     do {
     ^



  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 zero
     if ((ret != 0) || (*cur != 0) || !VALID_DATETIME((&(dt->value.date))))
                                       ^

"xmlschemastypes.c", line 1699: warning #2186-D: pointless comparison of unsigned integer with zero
     if ((ret != 0) || (*cur != 0) || !VALID_DATETIME((&(dt->value.date))))
                                       ^


  The macros expands to quite a lot of code. Maybe running on the preprocessor
output 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 the
point 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 parameter
of 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 referenced
 thread_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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]