This is the mail archive of the
mailing list for the Cygwin project.
Re: [64bit] openldap compilation doesn't produce shared libraries
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 10 Jun 2013 11:53:05 +0200
- Subject: Re: [64bit] openldap compilation doesn't produce shared libraries
- References: <87sj13i801 dot fsf at oracle dot com> <51A8D6C0 dot 3060507 at users dot sourceforge dot net> <51B1945E dot 6060002 at users dot sourceforge dot net> <87obbil3hb dot fsf at VZELL-LAP dot de dot oracle dot com> <87wqq2cotj dot fsf at oracle dot com>
- Reply-to: cygwin-apps at cygwin dot com
On Jun 10 11:11, Dr. Volker Zell wrote:
> >>>>> Volker Zell writes:
> >>>>> Yaakov writes:
> >> Following up on this, I noticed that slapd's build process is quite broken,
> >> resulting in an invalidly formatted executable. The working method to create a
> >> linkable EXE is to just link it with
> >> -Wl,--export-all-symbols,--out-implib,libfoo.a, then link other modules with
> >> -Wl,path/to/libfoo.a. (Relying on -L flags for in-tree paths isn't always a
> >> good idea with libtool.)
> >> I took the liberty of fixing up the build of slapd both with and without modular
> >> backends/overlays. The patch and modified cygport(3) are in Ports git:
> >> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/openldap
> > You made my day. I am struggling with this since more than a week. I
> > actually managed to get a working slapd executable but the openldap test
> > suite still doesn't run. ldapsearch always core dumps. I will check out
> > your .cygport approach and see if it makes any difference. I'll try to
> > do it on monday...
> Building with your cygport file also results in ldapsearch core dumping :-(
> Running with strace gives:
> Exception: STATUS_ACCESS_VIOLATION at rip=004091D184A
> Stack trace:
> Frame Function Args
> 00000229D70 004091D184A (00000229DC0, 0000000036E, 006000424CD, 00000000374)
> 00000229D70 004091D22F2 (00000000000, 00000229F70, 00000229F40, 00000229E18)
These addresses are in some DLL. Check the installed DLLs with
`rebase -i /bin/*.dll' and the not-installed DLLs with objdump -h for their
addresses to find out which one this is.
> 00000229F40 005205B287C (00600040E60, 00000000000, 001800C0C93, 00000229F40)
> 00600042160 00100401DDB (0000038F194, 001802DFFDD, 00000000000, 0010040F4ED)
> 00000000000 0010040BD69 (0000022AB80, 00000000000, 00000000000, 00000000000)
The executable itself, probably main and another function called from main.
> 0000022AB80 001800483AE (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 0018004618B (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 0018004634F (00000000000, 00000000000, 00000000000, 00000000000)
Cygwin DLL, probably the normal startup via dll_crt0_1.
> 00000000000 0010040A4C1 (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 00100401010 (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 0007740652D (00000000000, 00000000000, 00000000000, 00077489300)
> 00000000000 00077AFC521 (00000000000, 00000000000, 00000000000, 00077489300)
This is the normal start up of the executable.
As for the addresses, I'd like to point out my mail from February again:
Maybe that should go into the user's guide at one point.
> The strace output is attached.
> Running under gdb doesn't work either. What am I doing wrong here ?
Did you build the entire stuff, including the libs, without optimization?
That helps a lot when debugging.
> vzell@leila /cygdrive/d/misc/src/release64/openldap-2.4.35-1/build/tests
> 10:40 AM > PATH=../../inst/usr/lib/debug/usr/bin:$PATH gdb ../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg
You cannot start the *.dbg file. It's just the file containing the
debug symbols, not the actual binary. What you should do is starting
the real binary:
$ gdb ./ldapsearch.exe
and then, if gdb complains that it can't find the debug symbols:
(gdb) symbol-file ../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg
> 43 89818 [main] ldapsearch 5512 fhandler_base::fstat_helper: 0 = fstat (\??\D:\misc\src\release64\openldap-2.4.35-1\build\tests\STARCE, 0x229C20) st_size=137414, st_mode=0x81A4, st_ino=15199648742446005st_atim=51B5931C.1BF62654 st_ctim=51B5931C.1BF62654 st_mtim=51B5931C.1BF62654 st_birthtim=51B5931C.1BF62654
> 24 89842 [main] ldapsearch 5512 fstat64: 0 = fstat(1, 0x229C20)
> --- Process 1028, exception c0000005 at 00000004091D184A
I don't know what's causing this, but this very certainly occurs
inside of the DLL located at or around 0x4:091d0000, after a call
to fstat for the file STARCE.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com