Closed Bug 22781 Opened 20 years ago Closed 20 years ago

AIX 4.3.2 build has problem

Categories

(SeaMonkey :: Build Config, defect, P3)

Other
AIX
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jsalter, Assigned: cls)

References

Details

Attachments

(3 files)

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.
Status: NEW → ASSIGNED
Depends on: 23304
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.
Assignee: wtc → cls
Status: ASSIGNED → NEW
I fixed build issue #1 (as bug #23304).

Reassigned the bug to cls@seawood.org to look at
build issue #2.
Blocks: 18688
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
Attached patch Revised patch.Splinter Review
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
Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.