This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Xerces-C: two issues with gcc4/cygwin-1.7

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 '
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

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"
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/.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
Info: resolving xercesc_3_0::XMLPlatformUtils::fgMemoryManager        by
linking to __imp___ZN11xercesc_3_016XMLPlatformUtils15fgMemoryManagerE
Info: resolving xercesc_3_0::XMLUni::fgXercescDefaultLocale       by
linking to __imp___ZN11xercesc_3_06XMLUni22fgXercescDefaultLocaleE
Info: resolving std::cout  by linking to __imp___ZSt4cout (auto-import)
Info: resolving std::cerr  by linking to __imp___ZSt4cerr
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.
undefined reference to `typeinfo for xercesc_3_0::XMLException'
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.


Attachment: cygxerces-c-3-0.symbols.lzma
Description: Binary data

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]