Closed
Bug 188441
Opened 22 years ago
Closed 22 years ago
_USE_BIG_FDS flag needed on HPUX 11i
Categories
(NSS :: Build, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
3.3.4
People
(Reporter: sonja.mirtitsch, Assigned: wtc)
Details
Attachments
(1 file)
521 bytes,
patch
|
Details | Diff | Splinter Review |
Directoryserver ran out of file descriptors on HPUX 11i. The problem went away after they recompiled all their components with this flag. Nobody ever narrowed down the problem to NSS, but it was suspected that NSPR, DBM and NSS need this flag. Sun's version of NSS 3.3.3 was build with this flag set as were the NSPR and DBM versions it is based upon From the HP-UX Release Notes: "This feature is optional because it will not be often used and to minimize the impact on existing code. An application requiring more than 2048 file descriptors must be recompiled with the new symbol _USE_BIG_FDS defined. To do this, add the flag D_USE_BIG_FDS to the compile command in the application's makefile. Or, the symbol can be defined at the beginning of every application source file (via #define _USE_BIG_FDS)...." cvs server: Diffing . Index: HP-UXB.11.11.mk =================================================================== RCS file: /cvsroot/mozilla/security/coreconf/HP-UXB.11.11.mk,v retrieving revision 1.1.2.1 diff -r1.1.2.1 HP-UXB.11.11.mk 38a39 > OS_CFLAGS += -D_USE_BIG_FDS see also bug #184514 I have been unable to get more information about the problem
Assignee | ||
Comment 1•22 years ago
|
||
I believe that this change would be a no-op for NSS, JSS, and DBM (the current users of coreconf) because none of them are using 'fd_set'. I'm marking this WONTFIX unless someone can explain how it's going to affect NSS, JSS, or DBM. Also, -D_USE_BIG_FDS should only be added to the components that need it rather than to coreconf because coreconf is intended to be shared by multiple components. -D_USE_BIG_FDS may not be appropriate for some code.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 2•22 years ago
|
||
I build NSPR 4.1.3 and NSS 3.3.3 from sources that differ from the mozilla version enough, that I recommend branching and checking the source into a sun only repository on redbuild.
Reporter | ||
Comment 3•22 years ago
|
||
I would like to re-open discussions on this subject, our customer will not
accept a version of NSS that was built without the flag set, since they ran out
of file descriptors when they did.
We build DBM 1.55 and 1.61 as well as JSS with a coreconf/HP-UXB.11.11.mk that
set the flag
I need to generate a solarispatch next week and I do not want to build this
version of NSS again from files that differ from the version that is checked in.
> Also, -D_USE_BIG_FDS should only be added
> to the components that need it rather than to
> coreconf because coreconf is intended to be
> shared by multiple components. -D_USE_BIG_FDS
> may not be appropriate for some code.
where would be a good place to add it then?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee | ||
Comment 4•22 years ago
|
||
To the best of my knowledge, the _USE_BIG_FDS macro only affects the fd_set type (used by select()). I have searched the NSS and DBM source code and found no use of fd_set. This is why I believe recompiling NSS and DBM with -D_USE_BIG_FDS has no effect. If NSS needs -D_USE_BIG_FDS, we are supposed to add a new file mozilla/security/nss/config/config.mk, add -D_USE_BIG_FDS to that file, and have every NSS makefile include that file. (Every NSS makefile contains an empty section "(3) Include 'component' configuration information. (OPTIONAL)" for this purpose.) Obviously it is less work to just add -D_USE_BIG_FDS to coreconf.
Reporter | ||
Comment 5•22 years ago
|
||
> To the best of my knowledge, the _USE_BIG_FDS macro
> only affects the fd_set type (used by select()). I
> have searched the NSS and DBM source code and found
> no use of fd_set. This is why I believe recompiling
> NSS and DBM with -D_USE_BIG_FDS has no effect.
Are you certain enough that you recommend we tell our customer their problem
can't be related to NSS and give them a version that we build directly off the
NSS_3_3_BRANCH without the USE_BIG_FDS modification?
Comment 6•22 years ago
|
||
Since this is a preprocessor macro, couldn't we do one build without it, and one with, and show that the NSS bits are exactly the same?
Reporter | ||
Comment 7•22 years ago
|
||
the name of the build machine is hploan1, if it doesn't let you log in let me know, also let me know if you mean I should do this myself.
Assignee | ||
Comment 8•22 years ago
|
||
I am confident that your customer's problem can't be related to NSS. Fixing that PR_Poll bug or recompiling NSPR with -D_USE_BIG_FDS should suffice. We can compare the NSS binaries compiled with and without -D_USE_BIG_FDS. Just wanted to note that some compilers embed compile timestamps in the binaries, so you should first do two compiles of the same source tree to see if the HP compiler does that.
Reporter | ||
Comment 9•22 years ago
|
||
Ian are you going to build the 2 versions, or do you want me to do that? I can build it, but I feel not competent to do the comparison.
Comment 10•22 years ago
|
||
I'll try it tomorrow.
Comment 11•22 years ago
|
||
Unfortunately, my suggestion won't work. I did two builds on HP, without changing anything between them, and there were differences. I tried dumping the binaries as hex to see if it was just a one-line diff that would be in the same place (e.g., a timestamp), but there were actually a large number of differences. Maybe it timestamps each source file? Dunno.
Comment 12•22 years ago
|
||
patch for coreconf on NSS_3_3_BRANCH
Comment 13•22 years ago
|
||
patch checked into NSS_3_3_BRANCH, marking fixed. Will set milestone once I have 3.3.4 in bugzilla.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: fixed in 3.3.4
Updated•22 years ago
|
Whiteboard: fixed in 3.3.4
Target Milestone: --- → 3.3.4
You need to log in
before you can comment on or make changes to this bug.
Description
•