MOZ_MAKE_FLAGS=-j2 doesn't work with gnumake within LDAP

VERIFIED FIXED in mozilla1.0

Status

--
critical
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: tvl, Assigned: dmose)

Tracking

({smoketest})

other
mozilla1.0
smoketest

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

17 years ago
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

Comment 2

17 years ago
How urgent is this? Can we just fix it in the 5.0 LDAP C SDK (due to land soon,
from what I understand)?
(Assignee)

Comment 3

17 years ago
Unfortunately, it's still broken with the 5.0 SDK, and not just on windows.
OS: Windows 2000 → All
Hardware: PC → All

Comment 4

17 years ago
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[6]: *** [libprldap50.so] Error 1
gmake[6]: Leaving directory
`/builds/client/linux22/seamonkey/mozilla/directory/c-sdk/ldap/libraries/libprldap'
gmake[5]: *** [install] Error 2
gmake[5]: *** Waiting for unfinished jobs....
/usr/bin/ld: final link failed: File truncated
collect2: ld returned 1 exit status
gmake[6]: *** [libprldap50.so] Error 1
gmake[6]: Leaving directory
`/builds/client/linux22/seamonkey/mozilla/directory/c-sdk/ldap/libraries/libprldap'

Comment 6

17 years ago
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
Keywords: smoketest
Target Milestone: --- → mozilla1.0

Comment 7

17 years ago
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.

Comment 8

17 years ago
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

Updated

17 years ago
Blocks: 134923
(Assignee)

Comment 9

17 years ago
That's fine; this is mine.  I'll look at it today.
Status: NEW → ASSIGNED
(Reporter)

Comment 10

17 years ago
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?
(Assignee)

Comment 11

17 years ago
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

Updated

17 years ago
Keywords: nsbeta1
(Assignee)

Comment 12

17 years ago
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.
(Assignee)

Comment 13

17 years ago
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+
Created attachment 77310 [details] [diff] [review]
Alternative fix: single pass build
Comment on attachment 77308 [details] [diff] [review]
make ldap builds non-parallel; fix extra passes issues, v1

sr=sspitzer
Attachment #77308 - Flags: superreview+
(Assignee)

Comment 17

17 years ago
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+

Comment 19

17 years ago
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.

Comment 21

17 years ago
Regardless of what gets checked in right now, I think we should adopt the single
pass approach for LDAP in the long run.
(Assignee)

Comment 22

17 years ago
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
(Assignee)

Comment 23

17 years ago
Created attachment 77522 [details] [diff] [review]
single pass build, v2

Merge to the cvs tip.
Attachment #77310 - Attachment is obsolete: true

Comment 24

17 years ago
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!
(Assignee)

Comment 25

17 years ago
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.

a=rjesup@wgate.com for drivers
Attachment #77522 - Flags: superreview+
Attachment #77522 - Flags: approval+

Comment 27

17 years ago
ADT1 - lack of patch hides ldap bustage on tinderbox resulting in hours of tree
closure such as happened Tuesday.
Whiteboard: [adt1]

Comment 28

17 years ago
Adding adt1.0.0+ for the ADT.
Keywords: nsbeta1 → adt1.0.0+, nsbeta1+
(Assignee)

Comment 29

17 years ago
Fix checked in. Thanks cls!
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 30

16 years ago
Spam for bug 129472
QA Contact: nobody → nobody

Comment 31

16 years ago
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.