This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [64bit] openldap compilation doesn't produce shared libraries
- From: "Dr. Volker Zell" <dr dot volker dot zell at oracle dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 10 Jun 2013 14:46:12 +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> <20130610095305 dot GA32691 at calimero dot vinschen dot de>
>>>>> Corinna Vinschen writes:
> 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:
>>
>> ldapsearch.exe.stackdump:
>>
>> 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)
> Another DLL.
>> 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:
> http://cygwin.com/ml/cygwin-developers/2013-02/msg00027.html
> Maybe that should go into the user's guide at one point.
>> The strace output is attached.
> See below.
>> 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 [519]> 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.
Via similar calls (see one line below) to ldapsearch.exe and the not yet installed openldap libraries
awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e ../libraries/liblber/.libs/cyglber-2-4-2.dll
awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e ../libraries/libldap/.libs/cygldap-2-4-2.dll
awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e ../clients/tools/.libs/ldapsearch.exe
I think the stack trace
Stack trace:
Frame Function Args
00000229D70 004091D184A (00000229DC0, 0000000036E, 0060001A2FD, 00000000374)
00000229D70 004091D22F2 (00000000000, 00000229F70, 00000229F40, 00000229E18)
00000229F40 005205B287C (00600018C90, 00000000000, 001800C0C93, 00000229F40)
00600019F90 00100401DDB (0000026F194, 001802E98E5, 00000000023, 0010040F4ED)
00000000000 0010040BD69 (001802E6C10, 001802EA678, 00180067091, 0000022AB80)
0000022AB80 001800483AE (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 0018004618B (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 0018004634F (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 0010040A4C1 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 00100401010 (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 00076CC652D (00000000000, 00000000000, 00000000000, 00076D49300)
00000000000 000772BC521 (00000000000, 00000000000, 00000000000, 00076D49300)
End of stack trace
translates to the following:
Stack trace:
Frame Function Args
ber_get_stringbvl
/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:414
ber_scanf
/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:790
ldap_get_attribute_ber
/usr/src/debug/openldap-2.4.35-1/libraries/libldap/getattr.c:132
print_entry
/usr/src/debug/openldap-2.4.35-1/clients/tools/ldapsearch.c:1634
main
/usr/src/debug/openldap-2.4.35-1/clients/tools/ldapsearch.c:1222
0000022AB80 001800483AE (00000000000, 00000000000, 00000000000, 00000000000) <- cygwin dll
00000000000 0018004618B (00000000000, 00000000000, 00000000000, 00000000000) <- cygwin dll
00000000000 0018004634F (00000000000, 00000000000, 00000000000, 00000000000) <- cygwin dll
cygwin_crt0
/usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/lib/cygwin_crt0.c:22
mainCRTStartup
/usr/src/debug/cygwin-1.7.20-1/winsup/cygwin/crt0.c:34
00000000000 00076CC652D (00000000000, 00000000000, 00000000000, 00076D49300)
00000000000 000772BC521 (00000000000, 00000000000, 00000000000, 00076D49300)
End of stack trace
The offending code line
case BvOff:
res.bo = (char *) b->result + b->off;
((struct berval *) (res.bo + tot_size))->bv_val = NULL; <- line 414
tot_size = 0;
break;
If anybody can help with this, it would be much appreciated.
> Corinna
Ciao
Volker