Hi, Well, here is the compile command.
/bin/sh /home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool --silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32 -I./include/arch/unix -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include -o dso/win32/dso.lo -c dso/win32/dso.c && touch dso/win32/dso.lo And yes, #define APR_HAS_DSO 1 Thanks, Bob Rossi On Tue, Dec 05, 2006 at 03:11:30PM -0600, William A. Rowe, Jr. wrote: > If you force dlopen and dlsym to 0, see what happens. > > dso/win32/dso.c, is the source we should be compiling, not the > dso/unix/dso.c. Can you check that? > > Bob Rossi wrote: > > On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote: > >>> Failed Tests Total Fail Failed % > >>> =================================================== > >>> testdso 5 4 80.00% > >>> testpipe 9 2 22.22% > >> testpipe errors are expected. Filesystem pipes on windows do not behave > >> in a socket-compatible, select()able manner. > >> > >> testdso is another story - perhaps it believes it's using the dlxxx flavor > >> instead of windows, and some common code it causing it to throw up? > > > > Thanks for the quick response. This is the output of my configure run. > > Is something obviously wrong here? > > > > Checking for DSO... > > checking for NSLinkModule... no > > checking for shl_load in -ldld... no > > checking for dlopen... no > > checking for dlopen in -ldl... yes > > adding "-ldl" to LIBS > > checking for dlsym... yes > > > > Thanks, > > Bob Rossi > >
