On 3/10/2010 2:22 PM, ian balanza-davis wrote:
Hi
Yes, you are quite correct; I had some executables hanging around from a
previously-failed build.
Hopefully this lot makes more sense...
Ian
make -C src/xalanc all
make[1]: Entering directory `/xalan/src/xalanc'
Preparing the directory structure for a build ...
mkdir -p ../../obj
mkdir -p ../../lib
mkdir -p ../../bin
make -C Utils prepare
make[2]: Entering directory `/xalan/src/xalanc/Utils'
mkdir -p ../../../nls
mkdir -p ../../../nls/include
make[2]: Leaving directory `/xalan/src/xalanc/Utils'
make -C Utils locale
make[2]: Entering directory `/xalan/src/xalanc/Utils'
make[2]: Nothing to be done for `locale'.
make[2]: Leaving directory `/xalan/src/xalanc/Utils'
g++ -O -DNDEBUG -mthreads -fno-elide-constructors -DWIN32 -D_WINDOWS
-D__MINGW__ -DMINGW -fexceptions -DXALAN_INMEM_MSG_LOADER -c
-I/xalan/src -I/xalan/include -I../../nls/include -I/xerces/src/
-I/xerces/include/xercesc -I/xerces/include/ -o ../../obj/process.o
/xalan/src/xalanc/TestXSLT/process.cpp
g++ -DMINGW -mthreads -Wl,--allow-multiple-definition
-DXALAN_INMEM_MSG_LOADER \
-L../../lib -L/xalan/lib -lxalan-c -lm -mthreads -L/xerces/lib
-lxerces-c -L../../lib -lxalanMsg ../../obj/process.o -o
../../bin/testXSLT -L../../lib -L/xalan/lib -lxalan-c -lm -mthreads
-L/xerces/lib -lxerces-c -L../../lib -lxalanMsg
Info: resolving xalanc_1_11::XalanDOMString::s_empty by linking to
__imp___ZN11xalanc_1_1114XalanDOMString7s_emptyE (auto-import)
Info: resolving vtable for xalanc_1_11::XSLTInputSource by linking to
__imp___ZTVN11xalanc_1_1115XSLTInputSourceE (auto-import)
Info: resolving xercesc_3_1::XMLUni::fgXercescDefaultLocale by linking
to __imp___ZN11xercesc_3_16XMLUni22fgXercescDefaultLocaleE
(auto-importe:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe:
warning: auto-importing has been activated without --enable-auto-import
specified on the command line.
This should work unless it involves constant data structures referencing
symbols from auto-imported DLLs.)
g++ -O -DNDEBUG -mthreads -fno-elide-constructors -DWIN32 -D_WINDOWS
-D__MINGW__ -DMINGW -fexceptions -DXALAN_INMEM_MSG_LOADER -c
-I/xalan/src -I/xalan/include -I../../nls/include -I/xerces/src/
-I/xerces/include/xercesc -I/xerces/include/ -o ../../obj/TestXPath.o
/xalan/src/xalanc/TestXPath/TestXPath.cpp
g++ -O -DNDEBUG -mthreads -fno-elide-constructors -DWIN32 -D_WINDOWS
-D__MINGW__ -DMINGW -fexceptions -DXALAN_INMEM_MSG_LOADER -c
-I/xalan/src -I/xalan/include -I../../nls/include -I/xerces/src/
-I/xerces/include/xercesc -I/xerces/include/ -o
../../obj/NodeNameTreeWalker.o
/xalan/src/xalanc/TestXPath/NodeNameTreeWalker.cpp
g++ -DMINGW -mthreads -Wl,--allow-multiple-definition
-DXALAN_INMEM_MSG_LOADER \
-L../../lib -L/xalan/lib -lxalan-c -lm -mthreads -L/xerces/lib
-lxerces-c -L../../lib -lxalanMsg -O -DNDEBUG -mthreads
-fno-elide-constructors ../../obj/TestXPath.o
../../obj/NodeNameTreeWalker.o -o ../../bin/testXPath -L../../lib
-L/xalan/lib -lxalan-c -lm -mthreads -L/xerces/lib -lxerces-c
-L../../lib -lxalanMsg
Info: resolving xalanc_1_11::XalanDOMString::s_empty by linking to
__imp___ZN11xalanc_1_1114XalanDOMString7s_emptyE (auto-import)
Info: resolving xercesc_3_1::XMLPlatformUtils::fgMemoryManager by
linking to __imp___ZN11xercesc_3_116XMLPlatformUtils15fgMemoryManagerE
(auto-import)
Info: resolving xercesc_3_1::XMLUni::fgXercescDefaultLocale by linking
to __imp___ZN11xercesc_3_16XMLUni22fgXercescDefaultLocaleE
(auto-importe:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe:
warning: auto-importing has been activated without --enable-auto-import
specified on the command line.
This should work unless it involves constant data structures referencing
symbols from auto-imported DLLs.)
g++ -O -DNDEBUG -mthreads -fno-elide-constructors -mthreads
-Wl,--allow-multiple-definition
/xalan/src/xalanc/TestXPath/testXPath.cpp lib ../../bin/testXPath -o
testXPath
This command line is very strange. It looks like a default rule is being
used, but I have no idea why. Notice the difference between the compiler
options here and the options for building the testXSLT binary.
I will add that the testXPath executable is no longer being maintained,
so it's safe to ignore it. You could even remove it from the targets in
src/xalan/Makefile.in.
Dave
