158704 - NSPR libraries don't conform with Solaris versioning conventions

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Kirk Erickson]

Solaris 9 shipped with Directory Server.  As a result, NSS and NSPR were
bundled with libldap.so in Solaris 9.  The ABI team has requested that
NSS and NSPR Solaris libraries conform to versioning and library naming
conventions for the upcoming integration of Application Server
(in 2 months).

I filed bug 158683 agains NSS.  NSPR is more difficult, because there
is no convention in the buildtree for identifying public functions.
NSPR needs to create and link with a list of public functions
(Versioning map file).

NSPR is really a collection of libraries, the names of which appear
to be unique (unlike nss and ssl):

	libnspr4.so       -> libnspr.so.4
	libplc4.so        -> libplc.so.4
	libplds4.so       -> libplds.so.4
	libultrasparc4.so -> libultrasparc.so.4

Wan-Teh and I discussed a strategy for collecting the list
of public functions.  The complete set is identified by prefix:

	NSPR, ULTRASPARC functions beginning with PR_
	PLC,PLD functions beginning with PL_

are public.  I propose we generate nspr.def and plc.def, ...
in a fashion similiar to NSS.  We assume 'nspr' and 'plc' are
names we can reserve for these libraries, and start using
the Solaris naming convention on all platforms.

Comment 1

[Kirk Erickson]

Attachment: mapfile support for Solaris

Comment 2

[Kirk Erickson]

Attachment: defs (gzipped tar archive)

Comment 3

[Kirk Erickson]

Wan-Teh,

I believe the conclusion after feedback from Rod, the linker expert,
is that we can stick with the existing library names.

The above patch and defs.tar.gz attachments were done against 4.1.2.
Please review these maps and let me know if we can target the tip
with these changes.  If we know that the maps are good to go, we'll
feel better turning the 4.1.2 crank here with them.

Thanks.

Comment 4

[Kirk Erickson]

Attachment: mozilla/security/nss/pkg/ directory (.tar.gz)

Create NSPR 4.1.2 workarea
and apply the following patch:

Index: Makefile
===================================================================
RCS file: /cvsroot/mozilla/nsprpub/Attic/Makefile,v
retrieving revision 3.23
diff -u -r3.23 Makefile
--- Makefile	3 Jul 2000 21:41:19 -0000   3.23
+++ Makefile	18 Jul 2002 17:42:18 -0000
@@ -122,5 +122,9 @@
    cp -f mdheader.jar $(MDIST)/$(MOD_NAME)/$(BUILD_NUMBER)/$(OBJDIR_NAME); \
    chmod 664 $(MDIST)/$(MOD_NAME)/$(BUILD_NUMBER)/$(OBJDIR_NAME)/mdheader.jar

+solarispkg:
+   @echo Making Solaris packages.
+   cd pkg/solaris && $(MAKE) publish
+
 depend:
    @echo "NSPR20 has no dependencies.	Skipped."
Index: config/module.df
===================================================================
RCS file: /cvsroot/mozilla/nsprpub/config/module.df,v
retrieving revision 3.7
diff -u -r3.7 module.df
--- config/module.df	20 Jun 2000 21:16:10 -0000  3.7
+++ config/module.df	18 Jul 2002 17:42:18 -0000
@@ -38,3 +38,5 @@

 MOD_NAME = nspr20
 MOD_VERSION = 4
+MOD_MINOR = 1
+MOD_MICRO = 2

cd  ./mozilla/nsprpub
tar xzf <this attachment>
gmake solarispkg

This will create Solaris packages in
mozilla/dist/SunOS5.8_sparc_32_PTH_OPT.OBJ/pkgarchive

Comment 5

[Kirk Erickson]

Attachment: consolidated patch for NSPR 4.1.2

Here's a recipe for creating Solaris packages for NSPR 4.1.2.
The ingredients are:

/u/kirke/nss/158704/DIFFS	  (this attachment)
/u/kirke/nss/158704/newfiles.tar  (next attachment)

Create a workarea and build in the normal manner.

cd <workarea>
patch </u/kirke/nss/158704/DIFFS
tar xvf /u/kirke/nss/158704/newfiles.tar
cd mozilla/nsprpub
gmake solarispkg

That will generate
mozilla/dist/SunOS5.8_sparc_32_PTH_OPT.OBJ/pkgarchive

Copy to:
mccrel3/nspr20/v4.1.2/package/SunOS5.8_sparc_32_PTH_OPT.OBJ

This will migrate to /share/builds/integration
and evenutally /share/builds/components.

Comment 6

[Kirk Erickson]

Attachment: consolidated newfiles (tar archive)

This the second ingredient for the recipe include with
attachment 94178 [details] [diff] [review] above.

Comment 7

[Danek Duvall]

Patch 94178 won't work; the mapfile definitions need to be separated, each in
its own respective Makefile.

In addition, the new tar file includes files that will be generated:

    mozilla/nsprpub/pkg/solaris/SUNWnspr/depend
    mozilla/nsprpub/pkg/solaris/SUNWnspr/pkginfo
    mozilla/nsprpub/pkg/solaris/awk_pkginfo
    mozilla/nsprpub/pkg/solaris/bld_awk_pkginfo

Comment 8

[Kirk Erickson]

Attachment: consolidated patch for NSPR 4.1.2

Replaces Patch 94178.
Separated mapfile definitions into their respective Makefiles.

Comment 9

[Kirk Erickson]

Attachment: consolidated newfiles (tar archive)

Removed generated files: 
    mozilla/nsprpub/pkg/solaris/SUNWnspr/depend
    mozilla/nsprpub/pkg/solaris/SUNWnspr/pkginfo
    mozilla/nsprpub/pkg/solaris/awk_pkginfo
    mozilla/nsprpub/pkg/solaris/bld_awk_pkginfo

Comment 10

[Kirk Erickson]

Attachment: consolidated newfiles (tar archive)

Removed generated files: 
    mozilla/nsprpub/pkg/solaris/SUNWnspr/depend
    mozilla/nsprpub/pkg/solaris/SUNWnspr/pkginfo
    mozilla/nsprpub/pkg/solaris/awk_pkginfo
    mozilla/nsprpub/pkg/solaris/bld_awk_pkginfo

Comment 11

[Kirk Erickson]

Added Sonja Mirtitsch to the cc list.

Comment 12

[Kirk Erickson]

Attachment: consolidated newfiles (tar archive)

Updated mozilla/nsprpub/pkg/solaris/SUNWnspr/pkginfo.tmpl

NAME="Netscape Portable Runtime"
SUNW_PRODNAME="Netscape Portable Runtime"
SUNW_PRODVERS="4.1.2"

Comment 13

[Kirk Erickson]

Attachment: consolidated patch for NSPR 4.1.2

Had the map in the wrong Makefile for libnspr

ifeq ($(OS_ARCH),SunOS)
MAPFILE = $(OBJDIR)/nsprmap.sun
ALL_TRASH += $(MAPFILE)
MKSHLIB += -M $(MAPFILE)
endif

was in: mozilla/nsprpub/Makefile.
now in: mozilla/nsprpub/pr/src/Makefile

Comment 14

[Kirk Erickson]

There is a loose end with regard to libultrasparc4.so.
From what I recall, linking with this library enables the use
of native atomic instructions under Solaris 9.

I believe that, at least for the packaged version of NSPR, the 
Solaris guys are saying the linker can load this automagically.

This from Danek:
I'd like to also do the libultrasparc thing correctly.
I'll poke the linker guys about that; they promised us info on
how to do it right.

> I'd like to also do the libultrasparc thing correctly.

Actually, I just noticed that "libatomic.so" was being used as the name of
the auxiliary library, but "libultrasparc4.so" was what was actually being
created.  I assume this is an error that means that the sparcv9-specific
stuff never actually gets called?

---
Question for you, Joe -- you might recall that in NSPR, there's a filter
library (libatomic or libultrasparc; I'm not sure which name came through)
which is used to provide sparcv9-specific optimizations to a handful of
NSPR routines (I assume it's just plain sparcv9, not sparcv9+vis or
whatever -- Kirk?)

Anyway, I talked to Rod and he said that while it sounded like we were
doing the right thing with respect to ld, we probably weren't following
Solaris best practice when it came to naming the thing, but he wasn't sure
what that was.

Do you know what the right answer is here?  Do we stick it in /usr/platform
somewhere?  Or do we just create a /usr/lib/mps/sparcv9 and stick it there?

---
Gee, I'm not sure.

.../sparcv9/... really means "64 bit sparc"

Am I correct in assuming that this filter is for 32 bit interfaces
implemented on v9?

I think there might be a bigger issue here, in that there is a policy to
*not* pursue a specific, 32-bit v9 API, but lets not go there....   8^)

--
> Do we stick it in /usr/platform somewhere?  Or do we just create a
> /usr/lib/mps/sparcv9 and stick it there?

Actually, a question for you -- is it a problem if we rename it and stick
it in a subdirectory on Solaris?  Or should we, at least for now, just live
with the naming and fix it for the future?

The comment in SunOS5.mk says that the name of the library,
libultrasparc4.so, and the name of the filtee (using the Solaris linker
terms here), libatomic.so, are different so to force the user to create the
symlink so that it's not accidentally used.  But we can do that by sticking
libatomic.so in an architecture-specific subdirectory (like sparcv9), and
then pass '-f $ORIGIN/$ISALIST/libatomic.so', and it'll pick it up from the
right place on the right platform.

I think that's the better way of doing it, but it's different from what you
currently have, and may have unexpected consquences I'm not aware of.  Do
you have an opinion on this?

Wan-Teh, can you address these questions regarding the current implementation?
We can discuss remedies before or after the meeting today...

Comment 15

[Wan-Teh Chang]

Kirk,

You should do libultrasparc4.so correctly.

If you need the 64-bit Solaris version, use NSPR 4.2.  In
NSPR 4.2, the 64-bit Solaris version doesn't have
libultrasparc4.so.

In the following I am assuming that you only need the 32-bit
Solaris version of NSPR.  You can use either NSPR 4.1.2 or
NSPR 4.2.  I recommend NSPR 4.2.

libultrasparc4.so is built from one assembler file
(mozilla/nsprpub/pr/src/md/unix/os_SunOS_ultrasparc.s)
that is assembled with the '-xarch=v8plus' flag.

If my understanding is correct, I suggest that
1. You install libultrasparc4.so as
   /usr/lib/mps/sparcv8plus/libatomic.so.
2. You build libnspr4.so with the
   '-f $ORIGIN/$ISALIST/libatomic.so' flag.

Let me know if the name of the filtee, libatomic.so,
is too generic.  It probably should be libpratomic4.so,
or simply libultrasparc4.so (the original file name).
   

Comment 16

[Danek Duvall]

Attachment: New patch to be applied to the Sun package branch

This should fix the package build problems, as well as update the name of the
filtee to something pseudo-standard for Solaris.  Also, only build libnspr4.so
with the filtee, not all of them, but do use "-z combreloc" on all the shared
libraries.

Comment 17

[Kirk Erickson]

I created a workarea using Sonja's new branch tag:
NSPRPUB_RELEASE_4_1_2_SUN_PKG_BRANCH

Then tested Danek's patch: 
attachment (id=94640)

After cleaning and rebuilding, the solarispkg tag worked fine.
So I checked in Danek's changes.  

Wan-Teh has agreed to incorporate these changes at the tip of the
NSPR tree.  NSPR 4.2 presents the same API as 4.1.2; the major
version was rolled because the NSPR build/Makefile setup was
revamped to use autoconf.  There may be adjustments to the changes
to deal with autoconf differences, but the new map files and
packaging infrastructure should match.

In the 4.1.2 branch, we've hardcoded the version numbers in
mozilla/nsprpub/config/module.df.  At the tip we should be preprocessing
to ascertain the version numbers dynamically from prinit.h.

Michael wants to understand why the libatomic.so mechanism is broken
at 4.1.2, and what is the magnitude of changes necessary to support
64-bit too.

We need to avoid touching 'gmake release', so building packages is
not forced on the AOL folks.  Sonja and I will work to augment
'gmake solarispkg' or add and an additional 'releasepkg' to
copy to packages into the release area.

For the record, Sonja wrote:

The other thing we mentioned in the meeting was, that the solarispkg.
target needs to copy the files from dist/<OS> to a package directory
see make variable RELEASE_TREE, script release.pl - maybe you can call
it PACKAGE_TREE, set it to the same thing, only package instead of
ships. Let me know if you need more info on this.

Comment 18

[Danek Duvall]

> NSPR 4.2 presents the same API as 4.1.2; the major version was rolled because
> the NSPR build/Makefile setup was revamped to use autoconf.  There may be
> adjustments to the changes to deal with autoconf differences, but the new map
> files and packaging infrastructure should match.

A nit: 4.1.2 -> 4.2 changes the minor, not the major.  A question: is the
internal versioning of the library going to change as well, given that the API
have been left alone?  Ideally the version of the source could be decoupled from
the version of the library, but that might be too much to hope for.

> Michael wants to understand why the libatomic.so mechanism is broken at 4.1.2,
> and what is the magnitude of changes necessary to support 64-bit too.

I can't speak to the code changes necessary to make sure NSPR is 64-bit clean,
but building and packaging should be fairly simple.  I believe that putting the
64-bit library down would be done in the same way that we've changed libatomic
to do -- have a separate directory for the 64-bit version (sparcv9) and have the
64-bit library be a filtee called by the normal, 32-bit library.

I'm not sure how the "libatomic mechanism is broken", though.

Comment 19

[Kirk Erickson]

> is the internal versioning of the library going to change as well, given
> that the API have been left alone?  Ideally the version of the source
> could be decoupled from the version of the library, but that might be
> too much to hope for.

The practice with NSS has been to couple, rolling all the versions to
match the library version.  We can lobby for decoupling down the road.
I think the work you did correcting the hierarchialness will promote
proper practice.  We could add some "guideline" comments to the .def
files if you like.

I was merely making a feeble attempt to say we're done with the mapfile
portion of the work for 4.1.2, and we can count on this version
coexisting with future versions of SUNWnspr.

Comment 20

[Kirk Erickson]

> > Michael wants to understand why the libatomic.so mechanism is
> > broken at 4.1.2, and what is the magnitude of changes necessary
> > to support 64-bit too.
>
> I can't speak to the code changes necessary to make sure NSPR is
> 64-bit clean, but building and packaging should be fairly simple.
> I believe that putting the 64-bit library down would be done
> in the same way that we've changed libatomic to do -- have a
> separate directory for the 64-bit version (sparcv9) and have the
> 64-bit library be a filtee called by the normal, 32-bit library.
>
> I'm not sure how the "libatomic mechanism is broken", though.

I believe we're just not using the hardware (slow).
Sonja's QA of our new branch is passing and 64-bit packages are being
built fine.

kirke@soupnazi[618] pwd
/share/builds/mccrel3/nspr/nspr412/builds/20020809.2/yogibear_Solaris2.6/mozilla/dist
kirke@soupnazi[619] find . -name pkgarchive
./SunOS5.6_sparc_32_PTH_DBG.OBJ/pkgarchive
./SunOS5.6_sparc_32_PTH_OPT.OBJ/pkgarchive
./SunOS5.8_sparc_64_PTH_DBG.OBJ/pkgarchive
./SunOS5.8_sparc_64_PTH_OPT.OBJ/pkgarchive
./SunOS5.8_sparc_32_PTH_DBG.OBJ/pkgarchive
./SunOS5.8_sparc_32_PTH_OPT.OBJ/pkgarchive

When I diff the 32-bit OPT with the 64-bit:
diff -r ./SunOS5.8_sparc_64_PTH_OPT.OBJ/pkgarchive/SUNWnspr/pkginfo
./SunOS5.8_sparc_32_PTH_OPT.OBJ/pkg
archive/SUNWnspr/pkginfo
17c17
< PSTAMP=booboo20020809143447
---
> PSTAMP=booboo20020809143943
diff -r ./SunOS5.8_sparc_64_PTH_OPT.OBJ/pkgarchive/SUNWnspr/pkgmap
./SunOS5.8_sparc_32_PTH_OPT.OBJ/pkgarchive/SUNWnspr/pkgmap
4c4
< 1 i pkginfo 393 31480 1028928887
---
> 1 i pkginfo 393 31481 1028929183

They look identical saving the timestamp to the 32-bit bits.

Comment 21

[Sonja Mirtitsch]

what I am QAing at the moment is not this branch, sorry. 

I figured the changes here are too small to validate a formal QA of the code
changes, and a formal QA wouldn't tell us that much either.
What I had planned for QA was, install the NSS and NSPR packages on sparc
machines (Solaris 2.6, 8 and 9), then run regular NSS QA, with the
LD_LIBRARY_PATH pointing only to /usr/lib (or wherever the packages end up)
Please let me know soon if that doesn't seem sufficient.

Comment 22

[Danek Duvall]

Kirk said:

> They look identical saving the timestamp to the 32-bit bits.

It incorrectly picked up the 32-bit bits.  There are two bugs here -- one is
that the package makefile doesn't rebuild the ROOT target to point to the 64-bit
bits, and the other is that for Solaris at least, the 64-bit bits need to be put
in separate directories from their 32-bit counterparts.

We need also to get rid of the filtee library (libatomic) for sparcv9, since its
functionality can be rolled into the main 64-bit library.

Comment 23

[Sonja Mirtitsch]

there is a problem with the symlink from pkg/solaris/ROOT/usr/lib/mps ->
../../../../../../dist/<OS><VER>.OBJ/lib
the way the release build works, is having all platforms underneath the same
dist - so if we first build a DBG Solaris 2.6 solarispkg the same shared libs
will end up in OPT 2.6, and at the next build in DBG 2.8 and OPT 2.8 as well

kentuckyderby(62) pwd
/share/builds/mccrel3/nspr/nspr412/builds/20020812.1/yogibear_Solaris2.6/mozilla/nsprpub/pkg/solaris/ROOT/usr
kentuckyderby(63) cd lib
kentuckyderby(64) ls -l
total 0
lrwxrwxrwx   1 svbld    staff         56 Aug 12 00:16 mps ->
../../../../../../dist/SunOS5.6_sparc_32_PTH_DBG.OBJ/lib



kentuckyderby(87)  pwd
/share/builds/mccrel3/nspr/nspr412/builds/20020812.1/yogibear_Solaris2.6/mozilla/dist
kentuckyderby(88) ls
release                        SunOS5.6_sparc_32_PTH_OPT.OBJ 
SunOS5.8_sparc_32_PTH_OPT.OBJ  SunOS5.8_sparc_64_PTH_OPT.OBJ
SunOS5.6_sparc_32_PTH_DBG.OBJ  SunOS5.8_sparc_32_PTH_DBG.OBJ 
SunOS5.8_sparc_64_PTH_DBG.OBJ
kentuckyderby(89) ls -l */pkgarchive/SUNWnspr/reloc/usr/lib/mps/libnspr4.so
-rw-r--r--   1 svbld    staff    4115684 Aug 12 00:16
SunOS5.6_sparc_32_PTH_DBG.OBJ/pkgarchive/SUNWnspr/reloc/usr/lib/mps/libnspr4.so
-rw-r--r--   1 svbld    staff    4115684 Aug 12 00:16
SunOS5.6_sparc_32_PTH_OPT.OBJ/pkgarchive/SUNWnspr/reloc/usr/lib/mps/libnspr4.so
-rw-r--r--   1 svbld    staff    4115684 Aug 12 00:16
SunOS5.8_sparc_32_PTH_DBG.OBJ/pkgarchive/SUNWnspr/reloc/usr/lib/mps/libnspr4.so
-rw-r--r--   1 svbld    staff    4115684 Aug 12 00:16
SunOS5.8_sparc_32_PTH_OPT.OBJ/pkgarchive/SUNWnspr/reloc/usr/lib/mps/libnspr4.so
-rw-r--r--   1 svbld    staff    4115684 Aug 12 00:16
SunOS5.8_sparc_64_PTH_DBG.OBJ/pkgarchive/SUNWnspr/reloc/usr/lib/mps/libnspr4.so
-rw-r--r--   1 svbld    staff    4115684 Aug 12 00:16
SunOS5.8_sparc_64_PTH_OPT.OBJ/pkgarchive/SUNWnspr/reloc/usr/lib/mps/libnspr4.so

Comment 24

[Danek Duvall]

A 'make clobber' in the pkg/solaris directory will remove the pseudo-proto area
(ROOT), leaving the 'make publish' to rebuild it with the new OBJDIR_NAME.

Alternatively, you could force $(ROOT)/usr/lib/mps to build each time, though
you'll have to make sure it gets removed, as you can't get ln to overwrite a
symlink.

This is one reason that a real proto area is useful.

Also, only one set of packages will be delivered, but I'm not sure whether those
will be debug or non-debug.

Comment 25

[Sonja Mirtitsch]

The automated release build works a certain way, and it does for all products. A
masterbuild is created, this masterbuild checks out the sources, and builds, at
least 2 builds, when it is ready the slave builds are started and create
subdirectories and symlinks into the masterbuild directory structure, their own
object directories are created underneath the source directories, and a gmake
release then symlinks the libraries from these platform specific subdirectories
 into the slave builds dist directory. 
 
I do not think any of the suggested solutions fit in with the system as it works
now, and we don't want to do big changes, maybe we can create a platform
specific directory (like for the objects)?

/share/builds/mccrel3/nspr/nspr412/builds/20020812.1/yogibear_Solaris2.6/mozilla/nsprpub/pkg/solaris/ROOT/usr/mps/SunOS5.6_sparc_32_PTH_DBG.OBJ/
/share/builds/mccrel3/nspr/nspr412/builds/20020812.1/yogibear_Solaris2.6/mozilla/nsprpub/pkg/solaris/ROOT/usr/mps/SunOS5.8_sparc_32_PTH_DBG.OBJ/
/share/builds/mccrel3/nspr/nspr412/builds/20020812.1/yogibear_Solaris2.6/mozilla/nsprpub/pkg/solaris/ROOT/usr/mps/SunOS5.6_sparc_32_PTH_OPT.OBJ/
/share/builds/mccrel3/nspr/nspr412/builds/20020812.1/yogibear_Solaris2.6/mozilla/nsprpub/pkg/solaris/ROOT/usr/mps/SunOS5.8_sparc_32_PTH_OPT.OBJ/

Comment 26

[Danek Duvall]

Attachment: patch to fix multi-target builds

That won't work, but this patch (or something like it) will create different
proto areas for different builds, which should be sufficient.

Comment 27

[Kirk Erickson]

Checked in attachment (id=94352) for ROOT-$OBJDIR fix,
along with new files and changes from Danek for 64-bits.

I cleaned, clobbered, rebuilt, and packaged fine under 5.8 (on soupnazi),
but after checkin and building virgin on frank (5.6):

cc -xstrconst -o SunOS5.6_sparc_32_PTH_OPT.OBJ/os_SunOS_32.o  -O -KPIC -DSVR4
-DSYSV -D__svr4 -D__svr4__ -DSOLARIS -DHAVE_FCNTL_FILE_LOCKING
-D_PR_HAVE_OFF64_T -D_REENTRANT -DHAVE_POINTER_LOCALTIME_R  -DFORCE_PR_LOG
-D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -DXP_UNIX -UDEBUG -DNDEBUG
-D_NSPR_BUILD_ -I../../../../../dist/SunOS5.6_sparc_32_PTH_OPT.OBJ/include
-I../../../../pr/include -I../../../../pr/include/private  -Wa,-P -c
os_SunOS_32.s
/usr/ccs/bin/as -o SunOS5.6_sparc_32_PTH_OPT.OBJ/os_SunOS_ultrasparc.o -K PIC -P
-D_ASM -D__STDC__=0 -xarch=v8plus os_SunOS_ultrasparc.s
ld -G -z text -z endfiltee -o SunOS5.6_sparc_32_PTH_OPT.OBJ/libnspr4_flt.so
SunOS5.6_sparc_32_PTH_OPT.OBJ/os_SunOS_ultrasparc.o
ld: fatal: option -z has illegal argument `endfiltee'
ld: fatal: Flags processing errors
gmake[4]: *** [SunOS5.6_sparc_32_PTH_OPT.OBJ/libnspr4_flt.so] Error 1
gmake[4]: Leaving directory
`/var/tmp/workarea-nspr412pkg/mozilla/nsprpub/pr/src/md/unix'

I did a virgin build after the checkin again on soupnazi fine.
So apparently this is 5.6 specific.

Michael said this morning that to avoid long package names,
we will settle soon on new ones:

SUNWnsprxd -> SUNWprxd
SUNWnsprd  -> SUNprd

Also, 'nss' is taken and he lobbyed for 'tls'.

Comment 28

[Sonja Mirtitsch]

I build NSS 3.3.2 pulling today's version of NSPR 4.1.2. Debug builds passed
(Solaris 2.6, 8 32 and 64 bit) but optimized failed building lib/freebl

I manually repeated the build SunOS5.8_OPT build with NSPR 4.1.2 RTM and it
passed ( replaced mozilla/dist/SunOS5.8_OPT.OBJ with yesterday's
mozilla/dist/SunOS5.8_OPT.OBJ which contained nspr 4.1.2 RTM import)

cc -o SunOS5.8_OPT.OBJ/mpi_sparc.o -c -O -KPIC -DSVR4 -DSYSV -D__svr4 -D__svr4__
-DSOLARIS -D_REENTRANT -DSOLARIS2_8 -D_SVID_GETTOD -xarch=v8plus -xchip=ultra2
-DXP_UNIX -UDEBUG -DNDEBUG -DNSS_USE_HYBRID -DMP_NO_MP_WORD
-DMP_ASSEMBLY_MULTIPLY -DMP_USING_MONT_MULF -DMP_USE_UINT_DIGIT 
-DMP_API_COMPATIBLE -I/usr/dt/include -I/usr/openwin/include
-I../../../../dist/SunOS5.8_OPT.OBJ/include  -I../../../../dist/public/security
-I../../../../dist/private/security -Impi  mpi/mpi_sparc.c
/usr/ccs/bin/as -o SunOS5.8_OPT.OBJ/mpv_sparcv8.o -xarch=v8plusa -K PIC
mpi/mpv_sparcv8.s
/usr/ccs/bin/as -o SunOS5.8_OPT.OBJ/montmulfv8.o -xarch=v8plusa -K PIC
mpi/montmulfv8.s
rm -f SunOS5.8_OPT.OBJ/libfreebl_hybrid_3.so
ld -G -h libfreebl_hybrid_3.so -B symbolic -z defs -z now -z text -M
mapfile.Solaris -o SunOS5.8_OPT.OBJ/libfreebl_hybrid_3.so
SunOS5.8_OPT.OBJ/ldvector.o SunOS5.8_OPT.OBJ/prng_fips1861.o
SunOS5.8_OPT.OBJ/sha_fast.o SunOS5.8_OPT.OBJ/md2.o SunOS5.8_OPT.OBJ/md5.o
SunOS5.8_OPT.OBJ/alg2268.o SunOS5.8_OPT.OBJ/arcfour.o SunOS5.8_OPT.OBJ/arcfive.o
SunOS5.8_OPT.OBJ/desblapi.o SunOS5.8_OPT.OBJ/des.o SunOS5.8_OPT.OBJ/rijndael.o
SunOS5.8_OPT.OBJ/dh.o SunOS5.8_OPT.OBJ/pqg.o SunOS5.8_OPT.OBJ/dsa.o
SunOS5.8_OPT.OBJ/rsa.o SunOS5.8_OPT.OBJ/mpprime.o SunOS5.8_OPT.OBJ/mpmontg.o
SunOS5.8_OPT.OBJ/mplogic.o SunOS5.8_OPT.OBJ/mpi.o SunOS5.8_OPT.OBJ/mpi_sparc.o
SunOS5.8_OPT.OBJ/mpv_sparcv8.o SunOS5.8_OPT.OBJ/montmulfv8.o  
../../../../dist/SunOS5.8_OPT.OBJ/lib/libsecutil.a 
-L../../../../dist/SunOS5.8_OPT.OBJ/lib/ -lplc4 -lplds4 -lnspr4 -lc
Undefined
		first referenced
 symbol  			    in file
PR_CreateOrderedLock               
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so
PR_FindNextCounterQname            
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so
PR_Trace                           
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so
PR_GetCounter                      
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so
PR_GetTraceNameFromHandle          
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so
PR_GetTraceEntries                 
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so
PR_IncrementCounter                
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so
PR_SetTraceOption                  
../../../../dist/SunOS5.8_OPT.OBJ/lib//libnspr4.so

....

Comment 29

[Sonja Mirtitsch]

Attachment: complete build log

Comment 30

[Danek Duvall]

Ok, this is caused by the map file inserting the undefined symbol into the
library, even though the function itself has been #ifdef DEBUG'ed away in the
optimized build.

I will have to find out what the right answer is here.  I assume that the
interface can't change depending on whether you're using debug or non-debug
libraries, so we could provide stub functions for each of these.  (Or
alternatively scope these functions locally if they're not actually part of the
NSPR API.)

We should probably also build all the libraries with -z defs so that this kind
of problem is caught as early as possible.

Comment 31

[Kirk Erickson]

Removed the following from nspr.def, because they are coming
up UNDEF in the optimized library.  These are ifdef DEBUG
functions that compile to nothing.

We can bring these back into the fold by linking with a 
distinct map for DBG when we go for developer packages.

PR_CreateOrderedLock		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_FindNextCounterQname		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_Trace                            SunOS5.8_OPT.OBJ/nsprmap.sun
PR_GetCounter                       SunOS5.8_OPT.OBJ/nsprmap.sun
PR_GetTraceNameFromHandle	    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_GetTraceEntries		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_IncrementCounter		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_SetTraceOption		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_DestroyTrace                     SunOS5.8_OPT.OBJ/nsprmap.sun
PR_GetCounterHandleFromName	    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_DecrementCounter		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_DestroyCounter		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_UnlockOrderedLock		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_RecordTraceEntries		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_GetCounterNameFromHandle	    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_CreateTrace                      SunOS5.8_OPT.OBJ/nsprmap.sun
PR_AddToCounter                     SunOS5.8_OPT.OBJ/nsprmap.sun
PR_FindNextTraceRname		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_DestroyOrderedLock		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_SubtractFromCounter		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_CreateCounter		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_GetTraceHandleFromName	    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_FindNextCounterRname		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_GetTraceOption		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_LockOrderedLock		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_FindNextTraceQname		    SunOS5.8_OPT.OBJ/nsprmap.sun
PR_SetCounter                       SunOS5.8_OPT.OBJ/nsprmap.sun

Comment 32

[Wan-Teh Chang]

Attachment: wtc's proposed changes

This patch is my proposed changes to the
NSPRPUB_RELEASE_4_1_2_SUN_PKG_BRANCH.

1. Two nits: use '$(MAKE) -C' and use MOD_PATCH
instead of MOD_MICRO.

2. I renamed the filtee libnspr_flt4.so.

3. I do not install an additional copy of the 64-bit
.so's in $(DIST)/lib/sparcv9.

4. I added the NSPR_4.0 version and separated the
NSPR 4.0 and NSPR 4.1 symbols.

5. I moved the LL_* symbols from NSPRprivate to
NSPR_4.0 because they are public symbols.

6. My changes to the files under nsprpub/pkg/solaris
are my guess.  Hopefully you can figure out what my
intention is and review the changes.

Comment 33

[Kirk Erickson]

Attachment: Force fatal linker errors for undefines (-z defs)

Needed to add -lc for -z defs to work without libc errors.

Comment 34

[Kirk Erickson]

I had a conflict attempting to lay wtc's patch on top of mine for -z defs.
We both edit mozilla/nsprpub/pr/src/Makefile.  I will come up with a 
combined patch, and test.  Danek, do you see anything wrong with Wan-Teh's
changes under nsprpub/pkg/solaris?

Comment 35

[Danek Duvall]

> 1. Two nits: use '$(MAKE) -C' and use MOD_PATCH instead of MOD_MICRO.

Fine.  Most folks at Sun call that third number micro, but if you prefer patch,
then I have no problems with it.

> 2. I renamed the filtee libnspr_flt4.so.

Why?  I named it as I did thinking of the base name of the library as
"libnspr4".  Then if we ever get any magic that attaches _flt automatically
(it's intended to be a generic filter label, although not currently with any
special magic), the two libraries can be associated better.

Of course, all this is an artifact of not naming the library libnspr.so.4 in the
first place.

> 3. I do not install an additional copy of the 64-bit .so's in
> $(DIST)/lib/sparcv9.

<shrug>  Honestly, I would strongly encourage you to create both the 32 and the
64 bit libraries in a single build, not only to avoid this problem, but also for
consistency (being positive you get the same bits).  It's not as if you should
be able to expect to install just the 64-bit libraries in the main lib
directory, so I don't see what two separate builds buys you.

> 4. I added the NSPR_4.0 version and separated the NSPR 4.0 and NSPR 4.1
> symbols.

Ok, that's a good idea.

> 5. I moved the LL_* symbols from NSPRprivate to NSPR_4.0 because they are
> public symbols.

Fine.

> 6. My changes to the files under nsprpub/pkg/solaris are my guess.  Hopefully
> you can figure out what my intention is and review the changes.

I'm not thrilled with the changes to the Makefile.  I would at least change the
first set of changes to say something like

    PROTO: \
         blah

    ifdef USE_64
    PROTO += $(ROOT)/usr/lib/mps/sparcv9
    endif

The second change has to be there if you're not going to have separate sparcv9
directories in $(DIST).  I'm not particularly happy about that, but it won't
break the build.  The rest of the changes are correct, modulo my comments above.

Ken, unless you want to wait to resolve my issues here, go ahead and combine the
patches.

Comment 36

[Wan-Teh Chang]

Comment on attachment 96048 [details] [diff] [review]
Force fatal linker errors for undefines (-z defs)

Kirk,

The -z defs flag should be added to DSO_LDOPTS in
mozilla/nsprpub/config/SunOS5.mk, which means you
will very likely also need to add -lc to
mozilla/nsprpub/lib/ds/Makefile and
mozilla/nsprpub/lib/libc/src/Makefile.

This patch is not necessary unless there is a
requirement that the symbols referenced by the .so's
be fully resolved.

Comment 37

[Danek Duvall]

-z defs is by no means required, but it's almost always a good idea, and would
have shown us the problem with the optimized builds much sooner.  It's the right
thing to do, and yes, it probably should be added to DSO_LDOPTS.

Comment 38

[Kirk Erickson]

Attachment: combined patch (-z defs, Wan-Teh's proposed patch)

This combined patch adds '-z defs' to DSO_LDOPTS in in
mozilla/nsprpub/config/SunOS5.mk.  I needed to add -lc in
mozilla/nsprpub/lib/ds/Makefile and
mozilla/nsprpub/pr/src/Makefile.

I left Wan-Teh's portion (attachment id=95947) intact in this
version after making several runs at ironing out 2, 3, and 6.
I'd like to discuss Danek's feedback with Wan-Teh before
or after the status meeting today, and checkin tomorrow.
Note, I will be out of town all day Friday.

I tested the patch as it stands, verifying the 'solarispkg' 
target works, and all.sh runs when when we engage the resulting
libs in our NSS 3.3.2 pkg tree.

Comment 39

[Kirk Erickson]

Attachment: combined patch (-z defs, Wan-Teh's proposed patch)

Sorry.	I did needed to edit -lc into mozilla/nsprpub/lib/libc/src/Makefile,
as Wan-Teh pointed out earlier too.  I've obsoleted the previous patches
folded into this one.

Comment 40

[Danek Duvall]

Patch looks fine, again modulo my comments, so if it builds successfully, go
ahead and check it in.  I'm around this afternoon between two and four for a
conference, or any time tomorrow.  I'm out Friday and next week.

Comment 41

[Kirk Erickson]

Ok.  I checked in the combined patch (id=96206).
We'll discuss Wan-Teh's contribution further today if possible.
Here's what's left to be done:

1. Address Danek's feedback regarding Wan-Teh's items 2, 3, and 6.
2. Change SUNWnspr to SUNWpr (and adjust prereq in NSS 332pkg).
	(Michael wants SUNWnss3 -> SUNWtls)
3. Remove ultrasparc.so from NSS and add to NSPR.
   Get 64-bit NSPR going (whats involved here?).

Comment 42

[Wan-Teh Chang]

Danek,

Thank you for your comments in comment #35.  Let me
explain the motivations behind my suggested changes.
My suggested changes have two goals.

1. Consistency with existing practices in NSPR.  This is
why I changed MOD_MICRO to MOD_PATCH (because a similar
C preprocessor macro is named PR_VPATCH) and changed
libnspr4_flt.so to libnspr_flt4.so (because all NSPR
shared libraries are named lib*4.so).  I know that
these do not conform to Solaris's best practices, but
I would like to have consistency within the NSPR module.

2. Minimal deviations from the original NSPR 4.1.2 build.
That is, put as much of the changes in nsprpub/pkg/solaris
as possible.  Then, the only changes to the original NSPR
4.1.2 build would be the linker mapfiles and the auxiliary
filtee.  This is why I removed the extra installation of
the 64-bit .so's under $(DIST)/lib/sparcv9 because we can
achieve the same effect by making $(ROOT)/usr/lib/mps/sparcv9
a symlink to $(DIST)/lib.

Comment 43

[Wan-Teh Chang]

Danek,

I have some questions.

1. What is the "-z combreloc" flag?  Does it have any
gotchas?  Since I am trying to minimize the deviations
from the original NSPR 4.1.2 libraries, I want to make
sure that all changes we make are either mandatory or
have a highly desirable benefit, and don't have any
limitations.

2. If all the exported symbols are public, can we do
without the NSPRprivate section in the mapfiles?

3. All NSPR .so's have a 'libVersionPoint' function
that is meant to be looked up with a dlsym call at run
time (although in one NSPR test we directly reference
this symbol).  This function is documented. Should this
symbol be moved to the NSPR_4.0 section or should it
remain in the NSPRprivate section?

Thanks.

Comment 44

[Danek Duvall]

> 1. What is the "-z combreloc" flag?  Does it have any gotchas?  Since I am
> trying to minimize the deviations from the original NSPR 4.1.2 libraries, I
> want to make sure that all changes we make are either mandatory or have a
> highly desirable benefit, and don't have any limitations.

There are no gotchas.  It's there to speed up symbol table loading, and is
purely benefit.  If you have concerns, [e-mail] can allay them for you.

> 2. If all the exported symbols are public, can we do without the NSPRprivate
> section in the mapfiles?

> 3. All NSPR .so's have a 'libVersionPoint' function that is meant to be looked
> up with a dlsym call at run time (although in one NSPR test we directly
> reference this symbol).  This function is documented. Should this symbol be
> moved to the NSPR_4.0 section or should it remain in the NSPRprivate section?

If you publish libVersionPoint to your customers as a symbol that they can
depend on, then it should be moved to NSPR_4.0 (leaving NSPRprivate empty and
removable).  If it's there purely for your own internal use (between libraries
as currently happens, or whatever), then it should remain in NSPRprivate.

Comment 45

[Wan-Teh Chang]

Danek,

Yes, we publish libVersionPoint to our customers as a
symbol that they can depend on.  The only difference
between libVersionPoint and the other NSPR public
functions is that libVersionPoint is supposed to be
looked up with a dlsym call and is not meant to be
directly referenced.  So I will move libVersionPoint
to NSPR_4.0.

I have another question about NSPRprivate.  In NSPR
we don't have any exported functions for internal use
between libraries. (There are such functions in NSS.)
However, there are some exported NSPR functions that
we strongly discourage our customers to use.  These
functions are declared in header files that are marked
as either "obsolete" or "private".  But we will
continue to support them in all future NSPR 4.x releases.

The "obsolete" functions are deprecated functions for
which a replacement function exists.  So I think they
should be in the NSPR_4.0 section.

The "private" functions are not really private, but
rather "friend" in the C++ sense.  These "friend"
functions depend on properties of the current NSPR
implementation.  No suitable replacements exist, and
in some special cases, such as to integrate NSPR-based
code with non-NSPR-based code, they are necessary.
So, it's not clear to me whether these "friend" functions
should be in NSPR_4.0 or NSPRprivate.  Any suggestions?

Thanks.

Comment 46

[Wan-Teh Chang]

Attachment: wtc's second patch

1. Link the .so's with -lc only on Solaris.  (SunOS 4.1.3
doesn't need this change.)

2. Add libVersionPoint to NSPR_4.0 in the mapfiles.

3. Try to do ifdef USE_64 in mozilla/nsprpub/pkg/solaris/Makefile
in the way Danek suggested.  I had to use :: (as opposed to :) to
specify PROTO's dependency because :: dependency can be used
multiple times for the same target.

4. Fixed a bug in mozilla/nsprpub/pkg/solaris/Makefile in
the creation of the symlink $(ROOT)/usr/lib/mps/sparcv9.

5. Removed the symbols that shouldn't be exported from nspr.def.
Added PR_StackPop and PR_StackPush (which the 'nm' command
reports as 'N', not 'T').  Added the PRP_* functions.

Comment 47

[Kirk Erickson]

Danek,

Any objections to checking in Wan-Teh's second patch?
Sorry we didn't call you yesterday, but a code review of other
NSS stuff took the discusion after 4pm.

This patch should address your concerns with 2 and 6,
and fixes the map (some PR_ are not public), and corrects
my -z defs checkin.

Comment 48

[Danek Duvall]

Attachment: new PROTO area rules

Eh.  Don't use :: rules if you can avoid them; even the gmake info page
deprecates them.  Try this patch on for size.

Comment 49

[Kirk Erickson]

Checked in wtc's second patch.
Verified beforehand that we build packages successfully,
and that NSS's all.sh script runs with the resulting libs engaged.

Danek will improve the PROTO rules section while I come up with
the name change (SUNWnspr -> SUNWpr) patch.

Subsequently, we'll shift our attention to:
http://bugzilla.mozilla.org/show_bug.cgi?id=158683 (NSS)

Comment 50

[Danek Duvall]

Attachment: new PROTO area rules

Updated attachment 96328 [details] [diff] [review] to reflect the last patch Kirk applied.

Comment 51

[Kirk Erickson]

Checked in Danek's new PROTO area rules.

Comment 52

[Kirk Erickson]

Checked in changes for name change:
	SUNWnspr -> SUNWpr
	SUNWnsprx -> SUNWprx
Verified we're still building packages successfully. 

The change removed subdirs:
	mozilla/nsprpub/pkg/solaris/SUNWnspr
	mozilla/nsprpub/pkg/solaris/SUNWnsprx
and added these subdirectories:
	mozilla/nsprpub/pkg/solaris/SUNWpr
	mozilla/nsprpub/pkg/solaris/SUNWprx

Comment 53

[Kirk Erickson]

Attachment: DEBUG slapd won't start fix

Sun folks reported that DEBUG slapd wouldn't start.
It complained that PR_CreateCounter was undefined.
The following symbols were DEBUG only, and were removed
from nspr.def to build optimized, since the optimized
build ifdef'd compilation of these away:

PR_CreateOrderedLock
PR_FindNextCounterQname
PR_Trace
PR_GetCounter
PR_GetTraceNameFromHandle
PR_GetTraceEntries
PR_IncrementCounter
PR_SetTraceOption
PR_DestroyTrace
PR_GetCounterHandleFromName
PR_DecrementCounter
PR_DestroyCounter
PR_UnlockOrderedLock
PR_RecordTraceEntries
PR_GetCounterNameFromHandle
PR_CreateTrace
PR_AddToCounter
PR_FindNextTraceRname
PR_DestroyOrderedLock
PR_SubtractFromCounter
PR_CreateCounter
PR_GetTraceHandleFromName
PR_FindNextCounterRname
PR_GetTraceOption
PR_LockOrderedLock
PR_FindNextTraceQname
PR_SetCounter


The attached patch reintroduces these symbols, so
the optimized and debug builds share a common set of
global symbols.  In addition adding these back to
nspr.def (1.1.2.2 -> 1.1.2.1), the patch removes
the ifdefs from the .c files:

    mozilla/nsprpub/pr/src/misc/prolock.c
    mozilla/nsprpub/pr/src/misc/prcountr.c
    mozilla/nsprpub/pr/src/misc/prtrace.c

and shifting the #define's of the engaged macros
in the following include files:

    mozilla/nsprpub/pr/include/prcountr.h
    mozilla/nsprpub/pr/include/prtrace.h

This was to include the function declarations and
constants in the optimized build.

Wan-Teh made a similiar change to PR_Log previously.
The former "debug only" functions are compiled in the
optimized build, but only engaged when one of the
FORCE variables is defined:

    FORCE_NSPR_COUNTERS
    FORCE_NSPR_TRACE
    FORCE_NSPR_ORDERED_LOCK

Otherwise, the macros (ex. PR_CREATE_COUNTER) used by
NSPR clients are noops.

I've verified that we can build OPT or DBG with these
changes.  I will provide the reporter of this problem
with the resulting solaris package for testing.

Comment 54

[Wan-Teh Chang]

Comment on attachment 103339 [details] [diff] [review]
DEBUG slapd won't start fix

Kirk,

This patch should be correct, although I need to
ask you to modify the header files differently.

Instead of moving the macro definitions to the
end of the header files, I'd like you to move
the function declarations to the beginning of
the header files and leave the macro definitions
in their original position, so that they are next
to the comments that document them.

Thanks.

Comment 55

[Kirk Erickson]

Attachment: DEBUG slapd won't start fix (updated)

I've redone prcountr.h and prtrace.h.
This version of the includes moves each of the noop macros
up next to the enabled #define.

Comment 56

[Wan-Teh Chang]

Comment on attachment 103692 [details] [diff] [review]
DEBUG slapd won't start fix (updated)

Kirk,

This patch looks good.	Could you make the same
change to prolock.h?  Thanks.

Comment 57

[Kirk Erickson]

Attachment: DEBUG slapd won't start fix (updated)

Added fixes to prolock.h.

Comment 58

[Kirk Erickson]

Attachment: DEBUG slapd won't start fix (updated)

Added PR_GetSysfdTableMax() to nspr.def.

Comment 59

[Kirk Erickson]

Wan-Teh - Does our patch (id=104249) approved for checkin?
Sonja uses NSPRPUB_RELEASE_4_1_2_SUN_PKG_BRANCH in building
NSS_3_3_2_SUN_PKG_BRANCH. I think we want her turning
the crank with the all the latest packaging changes too both.

Comment 60

[Wan-Teh Chang]

Comment on attachment 104249 [details] [diff] [review]
DEBUG slapd won't start fix (updated)

r=wtc.	This patch is good, Kirk.

I will do a final review of the *.def files
to make sure that we export all the PR_ and
PL_ symbols.

I also found two minor problems.  A patch is
coming up.

Comment 61

[Wan-Teh Chang]

Attachment: Fix two minor problems

1. Added the definition of PROrderedLock when ordered
locking is not compiled in.

2. Deleted a redundant definition of the PR_DEFINE_TRACE
macro.

Kirk, please review and check in this patch on the SUN
PKG branch.

Comment 62

[Wan-Teh Chang]

Attachment: Add three export symbols to nspr.def

I compared the three *.def files with the symbols
that are currently exported from the three .so's.

I found that plc.def and plds.def are fine.  There
are three symbols we might want to add to nspr.def.

1. PR_SetSysfdTableSize: since we need to export
PR_GetSysfdTableMax, it seems that we should also
export PR_SetSysfdTableSize.  (Neither of these
functions is declared in any NSPR header file.)

2. GetExecutionEnvironment and SetExecutionEnvironment:
these functions were used by Netscape's port of the
old Sun Java VM.  I don't think anyone is using them
right now, but they are declared in the exported header
file "private/pprthred.h".

This patch adds these three symbols to nspr.def.

Note that I also found PR_FindLibrary is exported
from the standard libnspr4.so.	Since this function
is not declared in any NSPR header and it is not
that useful, I don't think we should add it to
nspr.def.  To be absolutely safe, you might want to
ask the all the servers (web server, directory server,
mail server, and app server) if they are using
PR_FindLibrary.

Comment 63

[Wan-Teh Chang]

Comment on attachment 104704 [details] [diff] [review]
Add three export symbols to nspr.def

Danek,

I think the GetExecutionEnvironment and
SetExecutionEnvironment symbols should
be put in a private interface.

Should that interface be called NSPRprivate
or NSPRprivate_4.0?

Comment 64

[Danek Duvall]

Just NSPRprivate.  Private sections don't really need to be versioned, since the
idea is that all exposed private interfaces are either completely unreliable (so
who cares about versioning) or their use is governed by a contract which would
say something along the lines of "we will notify all users if this changes ..."
which essentially pushes the versioning to an out-of-band mechanism.

That said, Solaris' libc does have versioned private sections, and I'm not sure
why.  Jarrett Rosenberg may be able to decipher that for you, if you care.

Comment 65

[Wan-Teh Chang]

Attachment: Add three export symbols to nspr.def, with the NSPRprivate section

This patch adds GetExecutionEnvironment and SetExecutionEnvironment
to the NSPRprivate section.

Comment 66

[Kirk Erickson]

Comment on attachment 104726 [details] [diff] [review]
Add three export symbols to nspr.def, with the NSPRprivate section

Reviewed, tested, and checked in Attachment #104726 [details] [diff].

Comment 67

[Wan-Teh Chang]

Comment on attachment 104674 [details] [diff] [review]
Fix two minor problems

Thank you, Kirk.  Please review and check in this
patch, too, if it's not too late.

Comment 68

[Kirk Erickson]

Comment on attachment 104674 [details] [diff] [review]
Fix two minor problems

Reviewed and checked in.
Map PROrderedLock and methods onto PRLock when ordered locking
is not compiled in.  Eliminated duplicate in prtrace.h.

Comment 69

[Kirk Erickson]

Attachment: solarispkg patch for the TIP (new files)

Danek,
Please review this first attempt at integrating all our
NSPRPUB_RELEASE_4_1_2_SUN_PKG_BRANCH changes at the TIP.
Wan-Teh is on vacation through Nov 13.

The integration was complicated by the switch between NSPR
4.1.2 and the TIP to autoconf.	The build is performed outside
nsprpub; configure processes Makefile.in files in nsprpub and
reference source there.  

I resorted to copying prototype_sparc and friends too, after
seeing pkgmk -f <with-a-relative-path> not find 'copyright'
which was copied to the current directory.  Perhaps I missed
something there...

To take a test drive, build an NSPR tree, extract the new
maps and pkg/solaris subtree, and make the new way:

mkdir $WORKAREA}
cd $WORKAREA}
cvs co mozilla/nsprpub
tar xvf 2002-1105-tip.tar
patch  <2002-1105-tip.patch

cd ${WORKAREA}/mozilla
rm -rf pkg
nsprpub/configure ${configureargs}
cd ${WORKAREA}/mozilla
gmake $gmakeargs
cd ${WORKAREA}/pr/tests $gmakeargs
gmake
cd ${WORKAREA}/pkg/solaris
gmake solarispkg

I renamed the filter library from libatomic.so to libnspr_flt4.so
But never saw it get generated, so I removed it from prototype_sparc.
I guess this is wrong, but wanted to see our first package :-)
Did we want to rely on the linker more?
Lets come up with a proposal...

I don't see the point of this in Makefile.targ:

$(MACHDATAFILES): %: ../common_files/%_$(MACH)
	$(RM) $@; cp ../common_files/$@_$(MACH) $@

even at 4.1.2.	I fiddled with this dependency, in an attempt
to get prototype_sparc copied, but I gather it was meant for
when they were in common_files. 

Also, we need to avoid hardcoding version numbers as we discussed.

Comment 70

[Kirk Erickson]

Attachment: solarispkg patch for the TIP

Patch for use with Attachment #105263 [details]

Comment 71

[Kirk Erickson]

Attachment: solarispkg patch for the TIP (new files)

Made 'solarispkg' copy pkg/solars to pkg/$(OBJDIR), and go there to
build packages.  This addresses the problems Sonja reported which
resulted from building in the same tree nfs'd from multiple platforms
simultaneously.  Also removed -$(MACH) and ROOT-$OBJDIR changes that
failed to address this problem.

Comment 72

[Kirk Erickson]

Attachment: solarispkg patch for the TIP

Patch to go with new files (106572).

Comment 73

[Kirk Erickson]

Attachment: solarispkg patch for the TIP (new files)

Removed hardcoded version numbers.

The TIP has these:
./mozilla/nsprpub/configure:685:NSPR_MODNAME=nspr20
./mozilla/nsprpub/configure.in:48:NSPR_MODNAME=nspr20
./mozilla/config/autoconf.mk:31:MOD_MAJOR_VERSION = 4
./mozilla/config/autoconf.mk:32:MOD_MINOR_VERSION = 2
./mozilla/config/autoconf.mk:33:MOD_REVISION_VERSION = 0

We now use these variables rather than constants in in module.df:
MOD_NAME = $(NSPR_MODNAME)
MOD_VERSION = $(MOD_MAJOR_VERSION)
MOD_MINOR = $(MOD_MINOR_VERSION)
MOD_PATCH = $(MOD_REVISION_VERSION)

Danek, 

Should we avoid changes to mozilla/nsprpub/config/module.df,
and simply use these variables directly in Makefile.com?

Makefile.com:23:PRODUCT_VERSION = $(MOD_VERSION).$(MOD_MINOR).$(MOD_PATCH)

I don't see MOD_NAME being used anywhere in pkg/solaris.

Specifically, what needs to be done to do the filter correctly?
If we can get past this, I believe we'll have a reasonable patch
for review.

Comment 74

[Kirk Erickson]

Attachment: solarispkg patch for the TIP

patch to go with the tarball (id: 106867)

Comment 75

[Kirk Erickson]

Attachment: 106867: solarispkg patch for the TIP (new files)

Now building/packaging mps/cpu/sparcv8plus/libnspr_flt4.so
Changing the name of libultrasparc4.so is something I hoped
to avoid, but we want a single libnspr4.so, which is linked
once with a single -f argument.

Comment 76

[Kirk Erickson]

Attachment: solarispkg patch for the TIP

Patch to accompany tarball (id=107398)

Comment 77

[Wan-Teh Chang]

Kirk,

I've checked in your solarispkg patch for the TIP
with some modifications.

Please test the tip of NSPR and see if my modifications
break the solarispkg target.

Comment 78

[Kirk Erickson]

Thanks Wan-Teh. I verified packages build at the TIP on these:
SunOS iws-perf 5.8 Generic_108528-16 sun4u sparc SUNW,Ultra-4
SunOS phaedrus 5.8 Generic_108529-12 i86pc i386 i86pc

Closing.

Comment 79

[Roland Mainz]

Are there any plans to provide some pkg "glue" for Mozilla/Phoenix/GRE, too ?

Comment 80

[Kirk Erickson]

> Are there any plans to provide some pkg "glue" for Mozilla/Phoenix/GRE, too ?
Not that I am aware of.