1. cvs co -r MOZILLA_1_7_BRANCH mozilla/client.mk; cd mozilla; makie -f client.mk checkout 2. cd ..; mkdir opt; cd opt; ../mozilla/configure/; make (no mozconfig) cmd /c perl ../../../../../../mozilla/directory/c-sdk/ldap/build/genexports.pl Win32 Standard ../../../../../../mozilla/directory/c-sdk/ldap/libraries/libprldap/libprldap.ex 5.0 50 > ../../../../../../mozilla/directory/c-sdk/ldap/libraries/libprldap/../msdos/winsock/nsldappr32.def ======= making ./nsldappr32v50.dll sh ../../../../../../mozilla/directory/c-sdk/config/cygwin-wrapper link /DEBUG /nologo /MAP /DLL /PDB:NONE /DEBUGTYPE:BOTH /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 odbc32.lib odbccp32.lib winmm.lib c:/src/mozilla/moz-svk/opt/dist/lib/nsldap32v50.lib c:/src/mozilla/moz-svk/opt/dist/lib/plc4.lib c:/src/mozilla/moz-svk/opt/dist/lib/plds4.lib c:/src/mozilla/moz-svk/opt/dist/lib/nspr4.lib /out:"nsldappr32v50.dll" ./ldappr-dns.obj ./ldappr-error.obj ./ldappr-io.obj ./ldappr-public.obj ./ldappr-threads.obj /DEF:../../../../../../mozilla/directory/c-sdk/ldap/libraries/libprldap/../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 odbc32.lib odbccp32.lib winmm.lib c:/src/mozilla/moz-svk/opt/dist/lib/nsldap32v50.lib c:/src/mozilla/moz-svk/opt/dist/lib/plc4.lib c:/src/mozilla/moz-svk/opt/dist/lib/plds4.lib c:/src/mozilla/moz-svk/opt/dist/lib/nspr4.lib ../../../../../../mozilla/directory/c-sdk/ldap/libraries/libprldap/../msdos/winsock/nsldappr32.def : fatal error LNK1118: syntax error in "VERSION" statement LINK : fatal error LNK1141: failure during build of exports file make: *** [nsldappr32v50.dll] Error 117 make: Leaving directory `/cygdrive/c/src/mozilla/moz-svk/opt/directory/c-sdk/ldap/libraries/libprldap' System is WinXP with VC++ 6 and known to build Mozilla 1.7.2/1.7.3.
This is strange. I am not aware of any recent changes to the mozilla/directory code on MOZILLA_1_7_BRANCH. Please attach a copy of the generated mozilla/directory/c-sdk/ldap/libraries/msdos/winsock/nsldappr32.def file.
Created attachment 177529 [details] nsldappr32.def as generated This is the file content after running make. It gets rewritten in the source dir (which is a bug in itself).
Created attachment 177530 [details] nsldappr32.def after checkout That's how it is before running make.
I did not create the autoconf-based build for mozilla/directory/c-sdk, but I am pretty sure that genexports.pl script is not supposed to be used on Windows. I do not have a Windows build available to try this myself on, but mozilla.org's builds do not seem to run genexports.pl, e.g., http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.7/1110981660.29060.gz&fulltext=1 So what is different about your build procedure?
Created attachment 177635 [details] build log extract I pulled a fresh tree and followed your instructions (using VC 6 which is what I have installed also). The build got past the mozilla/directory portion of the build without errors (it failed later in the mozilla/jpeg code because I am missing the Processor Pack, but that is not relevant to this bug). So I am puzzled why it does not work for you.
ARG I realized what's up. I made the checkout on Linux. (I didn't mention it in my initial description, because I didn't even realize it, it's a matter of course for me, I did it since years without problems. Sorry for forgetting to mention it.) If I make the checkout on Windows, it works. So, the make -f client.mk checkout script is broken. I need that to transfer a tarball from Linux to Windows. Or to revision control outside cvs.mozilla.org.
It almost seems like part of the mozilla/directory/c-sdk configure was executed on Linux before you moved the files to Windows. Is that possible? I don't think the checkout procedure is different between platforms, but I am not 100% sure.
hm, I'm opretty sure I didn't run configure on the most recent tarball (and bash_history confirms). If anything, it might be the other way around: the tarballs that do work might have run configure on Linux, and the one breaking did not.
I'm not sure anymore that Windows vs. Linux is the problem. I spent a full day tryign to narrow down, without much success. The fact that it writes into the source dir while building doesn't make things easier. I also used -kk on some checkouts. I don't think on these, but mentioning just in case.
*sigh* Seems like the last modified time is a factor, too. Presumably, the makefile decides based on that, if to regenerate it. The version I have before building (which I check out from CVS) is just fine. Only if the makefile decides to regenerate it does it get malformed. That's what made my tracking down the problem so hard, because the source code version that works and the version that doesn't is *identical* in content, so |diff| shows nothing. So, the workaround is probably to just comment out that stupid genexports.pl. Marking the file readonly doesn't work (that was one of the first things I tried), because the build system then bails because it insists on writing it. Seems like my initial intuition was right and that would otherwise have worked. As mentioned in comment 2, the Makefile rule is wrong anyways, because the build is not allowed to change the source dir (if using objdir, as I do).
You are right, changing the source tree is an annoying thing to do. I guess the genexports command is not executed in most cases because the generated files checked into CVS are newer than the libldap.ex files, etc. On most platforms, the generated files are not checked into CVS at all; Win32 is an exception because in the distant past genexports did not work on Win32 (apparently, it is not working correctly for you). Dan, do you remember anything about this issue from when you worked on the autoconf-based build for mozilla/directory/c-sdk?
For the record, if you run into this, the immediate workaround is: In the source: 1. restore directory/c-sdk/ldap/libraries/msdos/winsock/nsldappr32.def (the failed build overwrote and horked it) 2. touch directory/c-sdk/ldap/libraries/msdos/winsock/nsldappr32.def (that's a cygwin command; changes the last modification time to now)
I don't remember the details of this, no. Is the right thing to do here to fix genexports to work on all platforms, and then cause it to always generate the files into the objdirs (and also removed any pregenerated ones from CVS)?
Any update on this?
I vote for making genexports.pl work on all platforms if that is easy (should be). I don't have time to work on that right now though.
I'm currently hitting this bug trying to build Thunderbird on windows. Ben's work around is not working for me. Any other suggestions on how to get this working? Below are my build errors: c:/builds/rklein/trunk/mozilla/directory/c-sdk/ldap/libraries/libldap/../msdos/winsock/nsldap32.def(1) : warning LNK4017: <<<<<<< statement not supported for the target platform; ignored c:/builds/rklein/trunk/mozilla/directory/c-sdk/ldap/libraries/libldap/../msdos/winsock/nsldap32.def(3) : fatal error LNK1118: syntax error in 'VERSION' statement LINK : fatal error LNK1141: failure during build of exports file
Try removing the .def files in msdos/winsock
Is this working now?
You need to log in before you can comment on or make changes to this bug.