612244 - HEAD of LDAP c-sdk doesn't compile with Thunderbird/SeaMonkey builds

Status: RESOLVED FIXED

(Directory :: LDAP C SDK, defect)

Description

[Mark Banner (:standard8)]

A while ago, some changes were made for supporting on building with msys:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fdirectory%2Fc-sdk&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2009-06-03+15%3A38&maxdate=2009-06-03+15%3A38&cvsroot=%2Fcvsroot

Unfortunately, these broke building Thunderbird/SeaMonkey with HEAD of the LDAP c-sdk:

link -MANIFEST:NO -LIBPATH:"e:/buildbot/tryserver-win32/build/objdir/mozilla/memory/jemalloc/crtsrc/build/intel" -NODEFAULTLIB:msvcrt -NODEFAULTLIB:msvcrtd -NODEFAULTLIB:msvcprt -NODEFAULTLIB:msvcprtd -DEFAULTLIB:mozcrt19 -DEFAULTLIB:mozcpp19 -OUT:"nsldappr32v60.dll" -DEBUG -OPT:REF -MAP -nologo -DLL -SUBSYSTEM:WINDOWS  -SUBSYSTEM:CONSOLE   wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib rpcrt4.lib uuid.lib winmm.lib e:/buildbot/tryserver-win32/build/objdir/mozilla/dist/lib/nsldap32v60.lib /LIBPATH:e:/buildbot/tryserver-win32/build/objdir/directory/sdks/c-sdk -out:"nsldappr32v60.dll" ./ldappr-dns.obj ./ldappr-error.obj ./ldappr-io.obj ./ldappr-public.obj ./ldappr-threads.obj   -DEF:e:/buildbot/tryserver-win32/build/directory/sdks/c-sdk/ldap/libraries/msdos/winsock/nsldappr32.def wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib rpcrt4.lib uuid.lib winmm.lib e:/buildbot/tryserver-win32/build/objdir/mozilla/dist/lib/nsldap32v60.lib /LIBPATH:e:/buildbot/tryserver-win32/build/objdir/directory/sdks/c-sdk
e:/buildbot/tryserver-win32/build/directory/sdks/c-sdk/ldap/libraries/msdos/winsock/nsldappr32.def(39) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored
   Creating library nsldappr32v60.lib and object nsldappr32v60.exp
ldappr-dns.obj : error LNK2019: unresolved external symbol __imp__PR_NetAddrToString referenced in function _prldap_getpeername
ldappr-dns.obj : error LNK2019: unresolved external symbol __imp__PR_GetPeerName referenced in function _prldap_getpeername
(unresolved external symbol continues)

As you can see, we've a mixture of -LIBPATH and /LIBPATH. I think that may be causing the issue.

Comment 1

[Mark Banner (:standard8)]

Anyone got any idea what's going on here? I'd really like to resolve this before cutting the next c-sdk release.

iirc, I tried this on windows with Mozilla Build and building the c-sdk on its own did required this patch, but somehow building it within Thunderbird it doesn't need the patch. Could there be some sort of wrapper or something getting in the way?

Comment 2

[[e-mail]]

Working command line for comparison (from last night's SeaMonkey nightly):

link -MANIFEST:NO -LIBPATH:"e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/memory/jemalloc/crtsrc/build/intel" -NODEFAULTLIB:msvcrt -NODEFAULTLIB:msvcrtd -NODEFAULTLIB:msvcprt -NODEFAULTLIB:msvcprtd -DEFAULTLIB:mozcrt19 -DEFAULTLIB:mozcpp19 -OUT:"nsldappr32v60.dll" -DEBUG -MAP -nologo -DLL -SUBSYSTEM:WINDOWS  -SUBSYSTEM:CONSOLE   wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib rpcrt4.lib uuid.lib winmm.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/nsldap32v60.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/nspr4.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/plc4.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/plds4.lib  -out:"nsldappr32v60.dll" ./ldappr-dns.obj ./ldappr-error.obj ./ldappr-io.obj ./ldappr-public.obj ./ldappr-threads.obj   -DEF:e:/builds/slave/comm-central-trunk-win32-nightly/build/ldap/sdks/c-sdk/ldap/libraries/msdos/winsock/nsldappr32.def wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib rpcrt4.lib uuid.lib winmm.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/nsldap32v60.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/nspr4.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/plc4.lib e:/builds/slave/comm-central-trunk-win32-nightly/build/objdir/mozilla/dist/lib/plds4.lib 
e:/builds/slave/comm-central-trunk-win32-nightly/build/ldap/sdks/c-sdk/ldap/libraries/msdos/winsock/nsldappr32.def(39) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored
   Creating library nsldappr32v60.lib and object nsldappr32v60.exp

Comment 3

[[e-mail]]

(In reply to comment #1)
> Anyone got any idea what's going on here? I'd really like to resolve this
> before cutting the next c-sdk release.
> 
> iirc, I tried this on windows with Mozilla Build and building the c-sdk on its
> own did required this patch, but somehow building it within Thunderbird it
> doesn't need the patch. Could there be some sort of wrapper or something
> getting in the way?
It helps to read the error messages!
../../../../comm/ldap/sdks/c-sdk/configure: line 1857: cd: $(DIST)/lib/nspr4.lib
 $(DIST)/lib/plc4.lib $(DIST)/lib/plds4.lib: No such file or directory

In LDAP, $(NSPR_LIBS) usually refers to the location of the libs, rather than the libs themselves, so it will contain a path name prefixed with -L. However because comm-central builds into mozilla/dist, all of the NSPR detection fails and it falls back on some special code that sets a magic LIBS_ALREADY_SET flag to tell build.mk not to supply the library names again while setting NSPR_LIBS to the libraries including full path names, rather than using -L. It also sets SKIP_CYGWIN_FIXUP to stop the subsequent code from mangling NSPR_LIBS but of course this fails if you're using MSYS as there's no skip in that case.

There would appear to be three options. The first is to skip the MSYS mangling if SKIP_CYGWIN_FIXUP is set. (Or better still, rename the variable too.) The second is to make the NSPR detection code actually work from comm-central. The third is to abolish LIBS_ALREADY_SET and SKIP_CYGWIN_FIXUP and set NSPR_LIBS to the -L path. However I'm not sure whether we can use $(DIST) at this point.

Comment 4

[[e-mail]]

(In reply to comment #3)
> The second is to make the NSPR detection code actually work from comm-central.
This is a non-starter because it needs NSPR to be built in order to detect it.

Comment 5

[[e-mail]]

Attachment: Possible patch

* Removed SKIP_CYGWIN_FIXUP because LIBS_ALREADY_SET means the same thing
* Removed CONVERT_LIBPATH from inside a cygwin-only block
* Added LIBS_ALREADY_SET test to MSYS fixup block

Comment 6

[[e-mail]]

Pushed changeset 16908ab2ab75 to projects/ldap-sdks