Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Building NSS for OpenCSW (Solaris)

41 views
Skip to first unread message

Maciej Bliziński

unread,
Nov 22, 2009, 7:44:16 AM11/22/09
to dev-tec...@lists.mozilla.org
Hello dev-tech-crypto,

I'm working on a Solaris NSS package for the OpenCSW[1] project. I'm
compiling it using Sun Studio 11, on standard OpenCSW buildfarm. I'm
using the standard OpenCSW build system, GAR. The source code of the
build file I'm writing is similar to BSD ports, and can be found in a
source code repository[2] together with patches I wrote[3].

I'm currently stuck at the problem of aborting shlibsign:

gmake[5]: Leaving directory
`/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/mangle'
cd SunOS5.8_OPT.OBJ ; sh
/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/./sign.sh
/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ
\
/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_OPT.OBJ
SunOS \
/opt/csw/lib/nspr
/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.so
/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_OPT.OBJ/shlibsign
-v -i /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.so
moduleSpec configdir='' certPrefix='' keyPrefix='' secmod=''
flags=noCertDB, noModDB
Abort - core dumped
gmake[4]: *** [../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.chk] Error 134
gmake[4]: Leaving directory
`/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign'

I've also built it with debugging symbols and ran it under a debugger.
Here's where it's aborting:

[1] 0xff3db7b0(0xffbfe220, 0xa3, 0x1, 0x6, 0x0, 0x6), at 0xff3db7b0
[2] 0xff3d7ff4(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3d7ff4
[3] 0xff3db710(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3db710
[4] raise(0x6, 0x0, 0x0, 0xffffffff, 0xfefc03cc, 0x29010), at 0xfef4bd1c
[5] abort(0xfefbc000, 0xff1b3e18, 0xff1b2984, 0x1494, 0x1e90c,
0x1400), at 0xfef35a34
=>[6] PR_NewLock_stub(), line 429 in "stubs.c"
[7] rng_init(), line 391 in "drbg.c"
[8] PR_CallOnce(0x1494, 0xfec3ac08, 0x1400, 0x27c24, 0xfecbdcfc,
0xff1b2984), at 0xff18adcc
[9] PR_CallOnce_stub(once = 0xfecbdcfc, func = 0xfec3ac08 =
&`libfreebl_32fpu_3.so`drbg.c`rng_init()), line 463 in "stubs.c"
[10] RNG_RNGInit(), line 469 in "drbg.c"
[11] RNG_RNGInit(), line 834 in "loader.c"
[12] nsc_CommonInitialize(pReserved = 0xffbfe8f4, isFIPS = 0), line
2582 in "pkcs11.c"
[13] NSC_Initialize(pReserved = 0xffbfe8f4), line 2710 in "pkcs11.c"
[14] softokn_Init(pFunctionList = 0xfee59224, configDir = (nil),
dbPrefix = (nil)), line 474 in "shlibsign.c"
[15] main(argc = 4, argv = 0xffbff314), line 802 in "shlibsign.c"

It looks like the stubs from stubs.c don't get overriden by real
functions. I've verified that shlibsign can find all the shared
libraries:

maciej@build8st [build8st]:~/src/opencsw/pkg/nss/trunk > ldd
/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_DBG.OBJ/shlibsign
/usr/lib/secure/s8_preload.so.1
libplc4.so => /opt/csw/lib/nspr//libplc4.so
libplds4.so => /opt/csw/lib/nspr//libplds4.so
libnspr4.so => /opt/csw/lib/nspr//libnspr4.so
libthread.so.1 => /usr/lib/libthread.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
librt.so.1 => /usr/lib/librt.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libaio.so.1 => /usr/lib/libaio.so.1
/opt/csw/lib/nspr/cpu/sparcv8plus/libnspr_flt4.so
/usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1

However, running shlibsign under a debugger doesn't show any signs of
loading nspr shared objects before it aborts:

(dbx) unOS5.8_DBG.OBJ/lib/libsoftokn3.so" <
Running: shlibsign -v -i
/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_DBG.OBJ/lib/libsoftokn3.so
(process id 1696)
Reading libsoftokn3.so
Reading libnssutil3.so
Reading libsqlite3.so.0
Reading libbsm.so.1
moduleSpec configdir='' certPrefix='' keyPrefix='' secmod=''
flags=noCertDB, noModDB
Reading libfreebl_32fpu_3.so
Reading libkstat.so.1
t@1 (l@1) signal ABRT (Abort) in (unknown) at 0xff3db7b0
0xff3db7b0: bcc,pt %icc,0xff3db7c4 ! 0xff3db7c4
Current function is PR_NewLock_stub
429 abort();

Why is ldd showing that the nspr libraries are found, but they don't
get loaded when running shlibsign? Do you have any hints?

Maciej

[1] http://www.opencsw.org/
[2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nss/trunk/Makefile
[3] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nss/trunk/files/

Wan-Teh Chang

unread,
Nov 22, 2009, 2:59:54 PM11/22/09
to mozilla's crypto code discussion list
2009/11/22 Maciej Bliziński <maciej.b...@gmail.com>:

>
> I've also built it with debugging symbols and ran it under a debugger.
>  Here's where it's aborting:
>
> [1] 0xff3db7b0(0xffbfe220, 0xa3, 0x1, 0x6, 0x0, 0x6), at 0xff3db7b0
>  [2] 0xff3d7ff4(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3d7ff4
>  [3] 0xff3db710(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3db710
>  [4] raise(0x6, 0x0, 0x0, 0xffffffff, 0xfefc03cc, 0x29010), at 0xfef4bd1c
>  [5] abort(0xfefbc000, 0xff1b3e18, 0xff1b2984, 0x1494, 0x1e90c,
> 0x1400), at 0xfef35a34
> =>[6] PR_NewLock_stub(), line 429 in "stubs.c"
>  [7] rng_init(), line 391 in "drbg.c"
>  [8] PR_CallOnce(0x1494, 0xfec3ac08, 0x1400, 0x27c24, 0xfecbdcfc,
> 0xff1b2984), at 0xff18adcc
>  [9] PR_CallOnce_stub(once = 0xfecbdcfc, func = 0xfec3ac08 =
> &`libfreebl_32fpu_3.so`drbg.c`rng_init()), line 463 in "stubs.c"
>  [10] RNG_RNGInit(), line 469 in "drbg.c"
>  [11] RNG_RNGInit(), line 834 in "loader.c"
>  [12] nsc_CommonInitialize(pReserved = 0xffbfe8f4, isFIPS = 0), line
> 2582 in "pkcs11.c"
>  [13] NSC_Initialize(pReserved = 0xffbfe8f4), line 2710 in "pkcs11.c"
>  [14] softokn_Init(pFunctionList = 0xfee59224, configDir = (nil),
> dbPrefix = (nil)), line 474 in "shlibsign.c"
>  [15] main(argc = 4, argv = 0xffbff314), line 802 in "shlibsign.c"
>
> It looks like the stubs from stubs.c don't get overriden by real
> functions.

You should not define FREEBL_NO_DEPEND when building NSS on
Solaris. The FREEBL_NO_DEPEND build configuration supports
only Linux.

Wan-Teh

Nelson B Bolyard

unread,
Nov 22, 2009, 4:08:53 PM11/22/09
to mozilla's crypto code discussion list
On 2009-11-22 04:44 PST, Maciej Bliziński wrote:
> Hello dev-tech-crypto,
>
> I'm working on a Solaris NSS package for the OpenCSW[1] project. I'm
> compiling it using Sun Studio 11, on standard OpenCSW buildfarm. I'm
> using the standard OpenCSW build system, GAR. The source code of the
> build file I'm writing is similar to BSD ports, and can be found in a
> source code repository[2] together with patches I wrote[3].
>
> I'm currently stuck at the problem of aborting shlibsign:
[snip]

> Why is ldd showing that the nspr libraries are found, but they don't
> get loaded when running shlibsign? Do you have any hints?

Yes, it's because of the changes you've made to freebl.

Considering that Solaris and OpenSolaris are among the main platforms for
which NSS is developed and supported (Sun presently employs most of the
NSS developers), you should not need to make any changes to NSS at all.
If you want to change the directory in which the shared libraries are
installed, and where they are searched, that's fine, a good idea.
But you should not need to make any other changes to NSS.

Be aware that the NSS team does not support downstream copies of NSS that
have been significantly modified by downstream developers. If you find bugs
in NSS, we encourage you to file bugs against the main upstream NSS source
code repository, and contribute patches.

Maciej Bliziński

unread,
Nov 23, 2009, 3:20:18 AM11/23/09
to mozilla's crypto code discussion list
On Sun, Nov 22, 2009 at 7:59 PM, Wan-Teh Chang <w...@google.com> wrote:
> 2009/11/22 Maciej Bliziński <maciej.b...@gmail.com>:

>> It looks like the stubs from stubs.c don't get overriden by real
>> functions.
>
> You should not define FREEBL_NO_DEPEND when building NSS on
> Solaris.  The FREEBL_NO_DEPEND build configuration supports
> only Linux.

Thanks a lot Wan, it solved the problem!

Maciej

Maciej Bliziński

unread,
Nov 23, 2009, 4:15:00 AM11/23/09
to mozilla's crypto code discussion list
On Sun, Nov 22, 2009 at 9:08 PM, Nelson B Bolyard <nel...@bolyard.me> wrote:
> On 2009-11-22 04:44 PST, Maciej Bliziński wrote:
>> Why is ldd showing that the nspr libraries are found, but they don't
>> get loaded when running shlibsign?  Do you have any hints?
>
> Yes, it's because of the changes you've made to freebl.

In this case the cause was the FREEBL_NO_DEPEND environment variable.

>> [1] http://www.opencsw.org/
>> [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nss/trunk/Makefile
>> [3] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/nss/trunk/files/
>
> Considering that Solaris and OpenSolaris are among the main platforms for
> which NSS is developed and supported (Sun presently employs most of the
> NSS developers), you should not need to make any changes to NSS at all.
> If you want to change the directory in which the shared libraries are
> installed, and where they are searched, that's fine, a good idea.
> But you should not need to make any other changes to NSS.

Ideally, I'd like to pass the -L and -R flags via environment
variables, especially since I'm building the library for both 32 and
64 bit architectures. Our build system expects builds to read the
flags via $LDFLAGS and $LD_OPTIONS:

Arch: sparc
Kernel: sparcv9

Default ISA 32: sparcv8
Default ISA 64: sparcv9

Requested ISAs: sparcv8 sparcv9 i386 amd64
Needed ISAs: sparcv8 sparcv9
Build ISAs: sparcv8 sparcv9

ISAEXEC dirs: /opt/csw/bin /opt/csw/sbin /opt/csw/libexec
ISAEXEC files:

Merge include:
Merge exclude: /opt/csw/share/info/dir /opt/csw/lib/.*\.la .*\~
/opt/csw/lib/.*\.a

Modulators: ISA
Modulations: isa-sparcv8 isa-sparcv9

Requested compiler flags:

* Modulation isa-sparcv8: ISA=sparcv8
Build Host =
PATH =
/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv8/opt/csw/bin:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv8/opt/csw/bin:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv8/opt/csw/sbin:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv8/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/studio/SOS11/SUNWspro/bin:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin
PKG_CONFIG_PATH = /opt/csw/lib/pkgconfig
CFLAGS = -g -xarch=v8 -I/opt/csw/include
CXXFLAGS = -g -xarch=v8 -I/opt/csw/include
CPPFLAGS = -I/opt/csw/include
LDFLAGS = -xarch=v8 -L/opt/csw/lib
LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib
ASFLAGS =
OPTFLAGS = -g -xarch=v8

* Modulation isa-sparcv9: ISA=sparcv9
Build Host =
PATH =
/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv9/opt/csw/bin/sparcv9:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv9/opt/csw/bin:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv9/opt/csw/sbin/sparcv9:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/work/install-isa-sparcv9/opt/csw/sbin:/opt/csw/bin/sparcv9:/opt/csw/bin:/opt/csw/sbin/sparcv9:/opt/csw/sbin:/opt/studio/SOS11/SUNWspro/bin:/home/maciej/src/opencsw/pkg/nss/branches/upstream-work/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin
PKG_CONFIG_PATH = /opt/csw/lib/64/pkgconfig
CFLAGS = -g -xarch=v9 -I/opt/csw/include
CXXFLAGS = -g -xarch=v9 -I/opt/csw/include
CPPFLAGS = -I/opt/csw/include
LDFLAGS = -xarch=v9 -L/opt/csw/lib/64
LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64
ASFLAGS =
OPTFLAGS = -g -xarch=v9

What's the best way to make the NSS build read LDFLAGS and LD_OPTIONS?

> Be aware that the NSS team does not support downstream copies of NSS that
> have been significantly modified by downstream developers.  If you find bugs
> in NSS, we encourage you to file bugs against the main upstream NSS source
> code repository, and contribute patches.

I guess the main need for changes are the nss-config and nss.pc files,
since other software packages require them to build. I've seen that
Linux distributions create those files downstream. Is there any
chance for upstream nss-config and nss.pc?

Maciej

Nelson B Bolyard

unread,
Nov 23, 2009, 2:32:10 PM11/23/09
to mozilla's crypto code discussion list
On 2009-11-23 01:15 PST, Maciej Bliziński wrote:

> I guess the main need for changes are the nss-config and nss.pc files,
> since other software packages require them to build. I've seen that
> Linux distributions create those files downstream. Is there any
> chance for upstream nss-config and nss.pc?

File a request for enhancement in bugzilla.mozilla.org and attach a patch
that adds the files you want to add. Then see what happens.

Robert Relyea

unread,
Nov 23, 2009, 4:00:25 PM11/23/09
to mozilla's crypto code discussion list
Please do. If there is more demand for these files, it seems reasonable
to add them.

bob

Wan-Teh Chang

unread,
Nov 23, 2009, 4:28:33 PM11/23/09
to mozilla's crypto code discussion list
2009/11/23 Robert Relyea <rre...@redhat.com>:

>
> Please do. If there is more demand for these files, it seems reasonable
> to add them.

There are already two bugs for nspr.pc:
https://bugzilla.mozilla.org/show_bug.cgi?id=290726
https://bugzilla.mozilla.org/show_bug.cgi?id=375284

Would be nice to open a bug for nss.pc and fix all of these.

Wan-Teh

Maciej Bliziński

unread,
Nov 23, 2009, 6:29:51 PM11/23/09
to mozilla's crypto code discussion list

I've filed a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=530672

Since there already are downstream patches, perhaps one of them could
be used? Gentoo's patch is relatively short and looks clean. I
linked to it from the bug.

Maciej

Jean-Marc Desperrier

unread,
Nov 24, 2009, 4:46:08 AM11/24/09
to
Maciej Bliziński wrote:
> I'd like to pass the -L and -R flags via environment
> variables

For anyone else, CSW packages use this to tell the builds to use
/opt/csw/lib to locate their dependencies.

> What's the best way to make the NSS build read LDFLAGS and LD_OPTIONS?

That's a very valid question, does the NSS build system read those
parameters from somewhere else ?

0 new messages