similiar to bug 132848 -j2 failes within the ldap directory as it trying to use the nsldab32v40.lib library before it's created. a fix like what's in bug 123423 might work here as a temp solution (haven't gotten a chance to test it yet)
Assignee: seawood → mcs
Status: UNCONFIRMED → NEW
Component: Build Config → LDAP C SDK
Ever confirmed: true
Product: Browser → Directory
QA Contact: granrose → nobody
How urgent is this? Can we just fix it in the 5.0 LDAP C SDK (due to land soon, from what I understand)?
Unfortunately, it's still broken with the 5.0 SDK, and not just on windows.
OS: Windows 2000 → All
Hardware: PC → All
confirmed on Solaris 8 and Solaris 9 using Forte and gmake.
Linux isn't immune, either; from the verification machine this morning: ======= making ./libprldap50.so gcc -shared -Wl,-soname -Wl,libprldap50.so -o libprldap50.so ./ldappr-dns.o ./ldappr-error.o ./ldappr-io.o ./ldappr-public.o ./ldappr-threads.o /usr/bin/ld: final link failed: File truncated collect2: ld returned 1 exit status gmake: *** [libprldap50.so] Error 1 gmake: Leaving directory `/builds/client/linux22/seamonkey/mozilla/directory/c-sdk/ldap/libraries/libprldap' gmake: *** [install] Error 2 gmake: *** Waiting for unfinished jobs.... /usr/bin/ld: final link failed: File truncated collect2: ld returned 1 exit status gmake: *** [libprldap50.so] Error 1 gmake: Leaving directory `/builds/client/linux22/seamonkey/mozilla/directory/c-sdk/ldap/libraries/libprldap'
raising severity of this bug to BLOCKER as it's already affecting most of the ports builds as well as the nightly verification Linux22 build.
Severity: normal → blocker
Target Milestone: --- → mozilla1.0
we need parallel builds working. If we have to workaround this problem temporarily by disabling parallel builds while building the LDAP SDK so be it, but this needs to get fixed.
I think this needs to be fixed in the autoconf build system, which dmose created. And I don't have time to work this. So reassigning to dmose (sorry Dan).
Assignee: mcs → dmose
That's fine; this is mine. I'll look at it today.
Status: NEW → ASSIGNED
just out of curiosity, since the hack to turn off parallel was ok for bug 132848 (nspr) why isn't it ok for ldap? it's not that i like the hack of turning off parallel, any chance the real fix for ldap can be taken back to nspr so we can fix both?
After discussion with leaf and jj, downgrading this to critical. None of the ports are broken because of this, and noone is being blocked from getting things done. This will still be the first thing I work on today.
Severity: blocker → critical
Talked this over with cls, and although just turning things down to -j1 in this part of the tree suboptimal, I'm completely swamped at the moment, so I think that's what's gonna have to happen for now. Patch coming up.
Created attachment 77308 [details] [diff] [review] make ldap builds non-parallel; fix extra passes issues, v1 OK, this patch does three things: It changes rules.mk to not bother with the libs target when making the all target. As far as I can tell, libs never actually causes anything to happen anywhere in the C SDK builds (mcs, can you confirm or deny?). It removes unnecessary LOOP_OVER_DIRS directives from two Makefile.ins, which should make a bunch of the parallelism problems go away. Because I think there are still a few more parallelism problems under the cover, it also uses the -j1 forcing hack previously mentioned.
Comment on attachment 77308 [details] [diff] [review] make ldap builds non-parallel; fix extra passes issues, v1 r=cls TVL, NSPR's -j build issues are different than LDAP's so the same fix won't work.
Attachment #77308 - Flags: review+
Comment on attachment 77308 [details] [diff] [review] make ldap builds non-parallel; fix extra passes issues, v1 sr=sspitzer
Attachment #77308 - Flags: superreview+
I'd like to land the original patch on the branch, and then let mcs decide what the right approach for the trunk is.
Comment on attachment 77308 [details] [diff] [review] make ldap builds non-parallel; fix extra passes issues, v1 a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77308 - Flags: approval+
The single pass approach seems simpler. On the other hand, approval and reviews are all in place for Dan's patch. Pardon my ignorance, but does the rest of the Mozilla client build use multiple passes or ?? I never pay much attention.
The rest of the Mozilla tree uses multiple passes, partially due to legacy MozClassic build code and partially due to our need to generate headers from .idl files for the entire tree before we can build. Since neither of those necessarily applies to LDAP, it could follow NSPR's path and just build the module in a single pass.
Regardless of what gets checked in right now, I think we should adopt the single pass approach for LDAP in the long run.
Comment on attachment 77308 [details] [diff] [review] make ldap builds non-parallel; fix extra passes issues, v1 Alright, let's punt on this and use cls' proposed fix instead.
Attachment #77308 - Attachment is obsolete: true
Created attachment 77522 [details] [diff] [review] single pass build, v2 Merge to the cvs tip.
Attachment #77310 - Attachment is obsolete: true
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the list if it doesn't even rate adt3.) Thanks!
Comment on attachment 77522 [details] [diff] [review] single pass build, v2 r=dmose
Attachment #77522 - Flags: review+
Comment on attachment 77522 [details] [diff] [review] single pass build, v2 Assuming that a request for approval from cls is equivalent in this case to sr=cls and so marking. firstname.lastname@example.org for drivers
ADT1 - lack of patch hides ldap bustage on tinderbox resulting in hours of tree closure such as happened Tuesday.
Adding adt1.0.0+ for the ADT.
Keywords: nsbeta1 → adt1.0.0+, nsbeta1+
Fix checked in. Thanks cls!
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Spam for bug 129472
QA Contact: nobody → nobody
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.