Hi Bereket, re: > Thank you so much! I really appreciate it! No worries. re: > I just quickly tried that and I am getting this error > log2ulog.c:14:19: fatal error: mutex.h: No such file or directory > #include "mutex.h" Hmm. I just tried building LDM-6.13.8 (supersedes LDM-6.13.7) in my CentOS 6.10 VM, and I get a different error related to log2ulog.c: /bin/sh ../libtool --tag=CC --mode=compile c99 -DHAVE_CONFIG_H -I. -I.. -I../misc -I../protocol2 -I./ulog -I/usr/include/libxml2 -g -O2 -MT lib_la-log2ulog.lo -MD -MP -MF .deps/lib_la-log2ulog.Tpo -c -o lib_la-log2ulog.lo `test -f 'log2ulog.c' || echo './'`log2ulog.c libtool: compile: c99 -DHAVE_CONFIG_H -I. -I.. -I../misc -I../protocol2 -I./ulog -I/usr/include/libxml2 -g -O2 -MT lib_la-log2ulog.lo -MD -MP -MF .deps/lib_la-log2ulog.Tpo -c log2ulog.c -fPIC -DPIC -o .libs/lib_la-log2ulog.o log2ulog.c: In function 'logi_set_destination': log2ulog.c:116: warning: implicit declaration of function 'lock' log2ulog.c:117: warning: dereferencing 'void *' pointer log2ulog.c:117: error: invalid use of void expression log2ulog.c:120: warning: implicit declaration of function 'unlock' log2ulog.c: At top level: log2ulog.c:157: error: conflicting types for 'logi_log' log_private.h:541: note: previous declaration of 'logi_log' was here log2ulog.c:169: error: conflicting types for 'logi_flush' log_private.h:551: note: previous declaration of 'logi_flush' was here log2ulog.c:182: error: conflicting types for 'logi_internal' log_private.h:565: note: previous declaration of 'logi_internal' was here Since this is an LDM "thing", I'll need to get our LDM developer involved. re: > Configure also had a warning at the end. > === configuring in mcast_lib/OESS-Client > (/usr/local/ldm/ldm-6.13.7/src/mcast_lib/OESS-Client) > configure: WARNING: no configuration information is in mcast_lib/OESS-Client This can safely be ignored in LDM-6.13.7 builds and will go away in LDM-6.13.8 builds. Comment: - based on my feedback on how newer LDMs do not include the uerror, unotice, etc. entry points in the static LDM library (~ldm/lib/libldm.a), our LDM developer made changes to an LDM-6.13.9 test distribution to include the entry points in the LDM library regardless of whether or not the end-user wants to use the system logging daemon method of logging or the newer logging package We are testing this version on several different machines now. I will be trying to build the ldm-mcidas decoders on one of these machines to see if the changes get around the problem you ran into yesterday. - it was also pointed out to me that all LDM-6.13.x releases have been using the new logging facility by default, so the problem you ran into should also be ran into for any LDM-6.13.x release Based on this, the easiest/quickest thing for you to do may be to build and install the last LDM-6.12 release; build the ldm-mcidas decoders against that release; and then use the LDM-6.13.[789] release for LDM operations.Since the ldm-mcidas decoders are statically linked against the LDM library, executables linked against an older LDM installation should run with no problems even when the LDM has been upgraded to a current release. I realize that this is not what I would call a "clean" approach, but it is probably the easiest way around the problem encountered at the moment. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: LMZ-903767 Department: Support ldm-mcidas Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.