Closed Bug 22781 Opened 20 years ago Closed 20 years ago
.3 .2 build has problem
I'm going to consolidate a bunch of relatively minor build issues on AIX 4.3.2 here - if you'd like them broken out, let me know. 1) configure on AIX 4.3.2 doesn't setup config/autoconf.mk with a -DAIX4_3 option - without it, the protypes.h include fails because AIX 4.3.x has int64 types defined in a system include. 2) config/autoconf.mk defines the /usr/ibmcxx/bin/makeC++SharedLib_r routine as SHLIB_BIN, but then doesn't use it as MKSHLIB of lib/prstreams/Makefile. 3) I installed the IDL function in /usr/lpp/idl and it failed to generate the correct paths even though I have LIBIDL_CONFIG set properly. 4) The dbm/src/h_bigkey.c file has C++ comments in it, which requires that I either use a C++ compiler, or that I add special options to the compiler to handle // comments.
Issue #1 is an NSPR bug (#23304). Issue #2: NSPR has its own autoconf build system. Variables defined by mozilla's configure are not used by NSPR's makefiles (in particular, lib/prstreams/Makefile in nsprpub). So it is NSPR's configure script that needs to be fixed. You can ignore this issue because mozilla does not use lib/prstreams.
I fixed build issue #1 (as bug #23304). Reassigned the bug to firstname.lastname@example.org to look at build issue #2.
18688 is my high level Mozilla AIX bug #
NSPR has its own autoconf build but it's not turned on by default and it's not readily apparently if jsalter used --enable-nspr-autoconf when building Mozilla. Even when using autoconf, the NSPR build is a separate entity. The only variables it inherits from the Mozilla configure are a few env variables passed into configure and the location of Mozilla's $(DIST). Both the classic & autoconf NSPR builds set MKSHLIB='$(LD) $(DSO_LDOPTS)' under AIX. Is this the correct behavior? Wrt #3, what is LIBIDL_CONFIG pointing to? It should just point to a script that tells the build which CFLAGS and LDFLAGS to use when building executables that use libIDL. It should not point to an idl executable itself. #4 should be fixed now.
I used all the default parameters - I didn't introduce any -enable-nspr-autoconf variable during the configure. The LIBIDL argument says specifically "full path to LIBIDL-config", which I took to mean /usr/lpp/idl/bin/LIBIDL-config. If that's incorrect, then the instructions for setting LIBIDL-config could use some clarification. AIX should be using the makeC++SharedLib_r command for creating shared libraries. Using AIX's C++ Set 3.1.x compiler, the location would be /usr/lpp/xlC/bin/makeC++SharedLib_r. Using AIX's C++ Set 3.6.x compiler, the location would be /usr/ibmcxx/bin/makeC++SharedLib_r.
Ok, I don't have an AIX box at my disposal so I can't check this. What I'm wondering though, is how NSPR AIX builds got by so far using $(LD) which doesn't appear to be set to makeC++SharedLib_r ?
NSPR has been building using LD for a while now. If you look at how NSPR uses LD on AIX you will notice it is similar to the makeC++SharedLib_r script (yes this is a script). So for #2, jsalter is correct, mozilla uses makeC++SharedLib_r but NSPR uses LD. However, I would like to know what is the problem? Is there a problem with NSPR using LD? Or are we just trying to make this consistent?
My take is that on AIX, shared libraries should always be built with the makeC++SharedLib_r routine. But you're right; it's just a shell script, and you can do the same thing using ld and options, so I guess that's ok. But I sure think it's a lot easier using it than hand-crafting the ld cmd line.
The NSPR component consists of several libraries. All the NSPR libraries are pure C code, except libprstrms3.so. libprstrms3.so is the only C++ library from the NSPR component. Note that the Mozilla browser does not use libprstrms3.so. The "classic" NSPR build system builds libprstrms3.so using the makeC++SharedLib_r shell script (see the AIX-specific definition of MKSHLIB in mozilla/nsprpub/lib/prstreams/Makefile). It is the new autoconf NSPR build system that is still using $(LD) to build libprstrms3.so. I suspect that you can override MKSHLIB in mozilla/nsprpub/lib/prstreams/Makefile.in similar to what the classic build system does.
Ugh. Those ifdefs buried deep in a sub-Makefile have to go. This patch makes check afor makeC++SharedLib_r in NSPR's configure.in, sets MKCPPSHLIB for AIX and uses MKCPPSHLIB to create shared libs if CPP_PROG_LINK is set.
Status: NEW → ASSIGNED
I removed nsprpub/lib/prstreams from NSPR build, so issue #2 is irrelevant now. Attachment 4479 [details] [diff] (which supersedes attachments 4477 and 4478) may be useful in the future if NSPR has C++ code again. At this point there are no plans to add C++ interfaces to NSPR. Has issue #3 been resolved? If so, this bug can be closed.
Depends on: 26844
Not sure about #3. jsalter, can you attach the output from your configure run & config.log to this bug?
mass re-assign of all bugs where i was listed as the qa contact
QA Contact: cyeh → chofmann
This looks pretty good now. Since I'm no longer at Netscape/iPlanet, I don't have an AIX system available. jdunn, can you confirm this bug has been fixed? I'm not going to be able to verify this one anymore...
#1: fixed. #2: irrelevant. I'm not planning to check in patch id=4479 because NSPR has no C++ code now. #3: unknown. Someone (maybe jdunn) needs to verify. #4: fixed in rev. 3.7 of h_bigkey.c.
My take is that #3 is a configuration issue and so should not be holding this up. I am not having any problems, so CLS, feel free to mark this fixed or whatever
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.