Man, I must say that your sending config.log.2.13 vs config.log.2.50
makes me extremely proud of the work we've done in the area!
Looking at the first failures:
configure:2576: checking for notifyAll in -lJTC
configure:2603: gcc -o conftest -g -O2 conftest.c -lJTC >&5
/tmp/ccO7oDLg.o: In function `main':
/home/torri/dgcc-debug/configure:2596: undefined reference to `notifyAll'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/libgcc.a(_eh.o): In function `eh_context_free':
/usr/src/bs/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc/../../gcc/libgcc2.c(.text+0x114):
undefined reference to `pthread_setspecific'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/libgcc.a(_eh.o): In function
`eh_threads_initialize':
/usr/src/bs/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc/../../gcc/libgcc2.c(.text+0x231):
undefined reference to `pthread_key_create'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/libgcc.a(_eh.o): In function
`eh_context_specific':
/usr/src/bs/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc/../../gcc/libgcc2.c(.text+0x38b):
undefined reference to `pthread_getspecific'
/usr/src/bs/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc/../../gcc/libgcc2.c(.text+0x3ab):
undefined reference to `pthread_setspecific'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/libgcc.a(_eh.o)(.data+0x0): undefined
reference to `pthread_create'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/libgcc.a(frame-dwarf2.o): In function
`decode_uleb128':
/usr/src/bs/BUILD/gcc-2.96-20000731/obj-i386-redhat-linux/gcc/../../gcc/frame-dwarf2.c(.data+0x0):
undefined reference to `pthread_create'
/usr/local/lib/libJTC.so: undefined reference to `pthread_detach'
/usr/local/lib/libJTC.so: undefined reference to `pthread_attr_setstacksize'
/usr/local/lib/libJTC.so: undefined reference to `pthread_cond_timedwait'
it seems to me thatlibJTC needs at least the pthreads. Therefore it
seems bizarre that you check for them afterwards. If I were you, I
would first try to compile a simple program by hand, see the
dependencies between those libs, and _then_ decide how to check for
them. You'll probably have to use OTHER-LIBRARIES too when writing
the macro calls. BTW, have a look at existing macros on
http://research.cys.de/autoconf-archive/
I doubt there are no existing macros for things such as threads.
PS/ - Macro: AC_CHECK_LIB (LIBRARY, FUNCTION, [ACTION-IF-FOUND],
[ACTION-IF-NOT-FOUND], [OTHER-LIBRARIES])
Depending on the current language(*note Language Choice::), try to
ensure that the C, C++ or Fortran 77 function FUNCTION is
available by checking whether a test program can be linked with the
library LIBRARY to get the function. LIBRARY is the base name of
the library; e.g., to check for `-lmp', use `mp' as the LIBRARY
argument.
ACTION-IF-FOUND is a list of shell commands to run if the link
with the library succeeds; ACTION-IF-NOT-FOUND is a list of shell
commands to run if the link fails. If ACTION-IF-FOUND is not
specified, the default action will prepend `-lLIBRARY' to `LIBS'
and define `HAVE_LIBLIBRARY' (in all capitals). This macro is
intended to support building of `LIBS' in a right-to-left
(least-dependent to most-dependent) fashion such that library
dependencies are satisfied as a natural side-effect of consecutive
tests. Some linkers are very sensitive to library ordering so the
order that `LIBS' is generated in is important to reliable
detection of libraries.
If linking with LIBRARY results in unresolved symbols, which would
be resolved by linking with additional libraries, give those
libraries as the OTHER-LIBRARIES argument, separated by spaces:
`-lXt -lX11'. Otherwise this macro will fail to detect that
LIBRARY is present, because linking the test program will always
fail with unresolved symbols. The OTHER-LIBRARIES argument should
be limited to cases where it is desirable to test for the library
in the presence of another (which may not already be in `LIBS').
