I've been trying to compile xerces-c 3.0 for cygwin-1.7, and I've run into two problems. First, the -lpthread issue showed up again:
*** Warning: linker path does not have real file for library -lpthread.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
$ cygcheck -cd cygwin
cygwin 1.7.0-46
I thought this had been fixed as of 1.7.0-45 -- or does libtool need a
tweak to accept the "new" libpthread.a as an import library?
$ nm -f posix -A /usr/lib/libpthread.a | grep ' I '
<nothing>
because all of the __imp__* symbols in libpthread.a are listed as ' U '.
Worse, looking at the objdump output:
$ objdump -f /usr/lib/libpthread.a | grep d000000.o
<nothing>
But, in the current speclib, d000000.o was added specifically for libtool:
...
# Add a dummy .idata object for libtool so that it will think
# this library is an import library.
my $iname_o = 'd000000.o';
$extract{$iname_o} = 1;
open my $as_fd, '|-', $as, '-R', '-o', $iname_o, "-";
print $as_fd <<EOF;
.section .idata\$7
.global $iname
$iname: .asciz "$dllname.dll"
EOF
close $as_fd or exit 1;
system $objcopy, '-j', '.idata$7', $iname_o;
...
So, help, please?
==============================================================
After I manually removed -lpthread from all the link commands, I was
able to build the library. However, the second issue I ran into was that
I couldn't link applications. This appears to be a gcc4 problem:
libtool: link: g++ -O2 -pipe -o .libs/CreateDOMDocument.exe
src/CreateDOMDocument/CreateDOMDocument.o
../src/.libs/libxerces-c.dll.a -L/usr/lib
/usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a /usr/lib/libcurl.dll.a
/usr/lib/libssh2.dll.a -lssl -lcrypto -lz -licuuc -licudata
-L/usr/lib/gcc/i686-pc-cygwin/4.3.2
Info: resolving xercesc_3_0::XMLPlatformUtils::fgMemoryManager by
linking to __imp___ZN11xercesc_3_016XMLPlatformUtils15fgMemoryManagerE
(auto-import)
Info: resolving xercesc_3_0::XMLUni::fgXercescDefaultLocale by
linking to __imp___ZN11xercesc_3_06XMLUni22fgXercescDefaultLocaleE
(auto-import)
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
Info: resolving std::cerr by linking to __imp___ZSt4cerr
(auto-import/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
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.
src/CreateDOMDocument/CreateDOMDocument.o:CreateDOMDocument.cpp:(.gcc_except_table+0xe8):
undefined reference to `typeinfo for xercesc_3_0::XMLException'
src/CreateDOMDocument/CreateDOMDocument.o:CreateDOMDocument.cpp:(.gcc_except_table+0xf0):
undefined reference to `typeinfo for xercesc_3_0::DOMException'
collect2: ld returned 1 exit status
)
I checked the export list from the DLL, and there are NO typeinfo
symbols exported at all. Does this appear to be a gcc4 bug, or is there
something specific I need to do to cause typeinfo stuff to be exported?
I've attached the full demangled list of symbols exported by the dll.
Third (well, sort of third -- it's not really a *problem* yet) I
anticipate that xerces-c compiled with current gcc-4 may still have a
few issues. It claims to provide clients with the ability to specify
custom memory allocation functions, but doesn't appear to do so by
overriding the *GLOBAL* new/delete. So, I'm not sure if the lack of
weak symbol support in gcc4/curr-binutils will cause a problem or not.
But that's a problem for another day.
--
Chuck
cygxerces-c-3-0.symbols.lzma
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
