Need to properly integrate libnspr_flt4.so (was: libultrasparc4.so)

RESOLVED FIXED in mozilla1.3beta

Status

defect
P3
normal
RESOLVED FIXED
18 years ago
15 years ago

People

(Reporter: rich.burridge, Assigned: cls)

Tracking

Trunk
mozilla1.3beta
Sun
Solaris

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Reporter

Description

18 years ago
In .../mozilla/nsprpub/pr/src/md/unix, on Solaris SPARC machines, if
built on an UltraSPARC machine, a libultrasparc4.so library is generated
which contains UltraSPARC specific assembler. If there is a symbolic link
libatomic.so to this library, then about 10% better performance is achieved
on UltraSPARC machines.

There needs to be a better way to integrate this into a Solaris SPARC
distribution. After thinking about this some more, there is a problem, 
with the idea on setting up that symbolic link if you are installing on 
an UltraSPARC machine. What if this was an enterprise install, then a
non-UltraSPARC user tried to run Mozilla/Netscape 6.5 from the same
directory? BOOM!

I chatted with one of the Unix wizards on IRC here at Sun, and he
suggested the following. Perhaps there is a simple way of doing this.
Apologies if I've misunderstood how libatomic.so is used.

----

<rfm>There is serious linker magic called processor specific filters that 
     allow you to do all this automatically at runtime.  You may not even 
     need a filter -- is libultrasparc.so a complete replacement for whatever
     libatomic.so points to on a non-ultrasparc?
<richb> rfm: yes (the alternative is a generic C routine).
<rfm> Hang on I need to find the right section of the linker manual to point 
      you to
<rfm> What's the earliest OS you're targeting?  2.6?
<richb> rfm: Solaris 7.
<rfm> Oh good
<richb> rfm: actually, i might be misleading you here. The way this works 
        is the code looks for and tries to dlopen() a libatomic.so if it's
        present. if that fails, it does the operation the "slow" way (with 
        a C routine). Hang on, I'll try to get you an LXR reference...
<rfm> Here it is:
<rfm> Look for the section "Instruction Set Specific Shared Objects" in the 
linker and
<rfm> libraries manual.  
<richb> rfm: what page are you on? I have a copy of that here.
<rfm> I think in this case what you do is put it in
      /$PKGROOT/lib/sparcv8plus/libatomic.so
<rfm> then put /$PKGROOT/lib/$ISALIST/libatomic.so in your LD_RUN_PATH
<richb> rfm: sneaky!
<rfm> then make sure the dlopen uses NULL for the path name (so the 
      RUN_PATH gets used)
<rfm> then the dlopen will find it if and only if the platform supports 
      the instruction set you need
<rfm> this even solves the problem of multiple machines using the same install
<richb> rfm: yes. very nice. thanks.
<rfm> Oops, dlopen with NULL may not work exactly as I wanted.  You might 
      have to set up a filter after all (make libatomic.so be a filter 
      naming $ISALIST/libultrasparc.so.1 as AUXILIARY.)  
<rfm> Ah, here's the right thing:  just dlopen("libatomic.so", ...) don't 
      use dlopen(NULL,)
<richb> okay. noted. thanks.
Reporter

Comment 1

18 years ago
Adding Chris to the interest list as he's a build/config wizard.
Priority: -- → P3

Comment 2

18 years ago
Rich:

A shared installation can be done as follows.

1. Install libultrasparc4.so in /$PKGROOT/lib.
2. Create subdirectory /$PKGROOT/lib/sun4u.
3. Add a symbolic link /$PKGROOT/lib/sun4u/libatomic.so,
   which points to ../libultrasparc4.so.
4. In the mozilla shell script, do 'uname -m' and add
   /$PKGROOT/lib/sun4u to LD_LIBRARY_PATH if the result
   is "sun4u".
Assignee: wtc → cls
Component: NSPR → Build Config
Product: NSPR → Browser
QA Contact: larryh → granrose
Version: 4.0 → other
Reporter

Comment 3

18 years ago
Thanks wtc, we'll give this a try! If possible, can we keep the bug 
open until we get a chance to report back?

Updated

18 years ago
Target Milestone: --- → mozilla0.9.2

Updated

18 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee

Updated

18 years ago
Target Milestone: mozilla0.9.3 → mozilla1.0
Is this still an issue?
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → Future

Comment 5

17 years ago
*** Bug 183822 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
I made two changes to NSPR's libultrasparc4.so
recently.  These changes will be in Mozilla 1.3 beta.
This means comment #2 (and similar instructions in
ug 183822 comment #5) will only apply to Mozilla
releases up to 1.3 alpha.

The two changes are:

1. libultrasparc4.so was renamed libnspr_flt4.so.

2. libnspr_flt4.so must be installed as
"cpu/sparcv8plus/libnspr_flt4.so", relative to
libnspr4.so.  That is, if libnspr4.so is installed
in directory <x>, libnspr_flt4.so should be installed
in directory <x>/cpu/sparcv8plus.  No changes to
the mozilla startup shell script are necessary.

I am not familiar with Mozilla's build tree structure,
distribution packaging, and installer, so Chris, could
you please come up with the necessary changes for NSPR
and Mozilla?
Summary: Need to properly integrate libultrasparc4.so → Need to properly integrate libnspr_flt4.so (was: libultrasparc4.so)
Target Milestone: Future → mozilla1.3beta

Comment 7

17 years ago
Is this only on the Sun C compiler (Sun One Studio now) or does this work for
gcc as well?

Comment 8

17 years ago
This is a linker feature and is independent of the
compiler.

Comment 9

17 years ago
wtc:
Dumb question:
What happens with your patch if someone compiles Mozilla as 64bit (=sparcv9)
application ? Will that hack/feature then be disabled automagically ?

Comment 10

17 years ago
Roland,

libnspr_flt4.so is only used in the 32-bit SPARC build.
It is not used in the x86 or 64-bit SPARC build.
Is it natural for every sparc platform combination to be tested when it tries
to load this lib?  I thought that it was going to use $ISALIST or whatever to
single it to one path.

sysinfo(514, "sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8
sparcv8-fsmul
d sparcv7 sparc", 257) = 85
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9+vis/libnspr_flt4.so"

, 0xFFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9/libnspr_flt4.so",
0x
FFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8plus+vis/libnspr_flt4

.so", 0xFFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/nsprpub/pr/src/md/unix/libnspr_flt4.so4.so"

, "/builds/cltbld/src/mozilla/nsprpub/pr/src/md/unix/libnspr_flt4.so", 1023) =
65
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8/libnspr_flt4.so",
0x
FFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8-fsmuld/libnspr_flt4.

so", 0xFFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv7/libnspr_flt4.so",
0x
FFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparc/libnspr_flt4.so",
0xFF
BEED20, 1023) Err#2 ENOENT
open("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9+vis/libnspr_flt4.so",
O_RDO
NLY) Err#2 ENOENT
open("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9/libnspr_flt4.so",
O_RDONLY)
 Err#2 ENOENT
open("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8plus+vis/libnspr_flt4.so",
O
_RDONLY) Err#2 ENOENT
open("/builds/cltbld/src/mozilla/nsprpub/pr/src/md/unix/libnspr_flt4.so",
O_RDONLY)
 = 3
fstat(3, 0xFFBEF094)		    = 0

Comment 12

17 years ago
Chris,

It will try the paths as specified by $ISALIST one by one
to look for the "filtee".  Because our filtee (libnspr_flt4.so)
is built with the -z endfiltee linker flag, it causes the search
to stop once it is found.

This is shown in the system call trace you provided.  open() was
not invoked on "sparcv8 sparcv8-fsmuld sparcv7 sparc" because the
open for "sparcv8plus" (with relative paths and symbolic links
resolved) succeeded.  However, the call trace did show that
resolvepath() was invoked on all the paths in $ISALIST.

What still needs to be done is to make sure that libnspr_flt4.so
gets packaged and installed on Solaris.  It seems that all we
need to do is to add "bin/cpu/sparcv8plus/libnspr_flt4.so" to
mozilla/xpinstall/packager/packages-unix, correct?
I forgot about the installer packages.	I was concentrating on the fact that
Sun was using the tarballs per
http://bugzilla.mozilla.org/show_bug.cgi?id=183822#c2 .

Comment 14

17 years ago
Comment on attachment 111894 [details] [diff] [review]
Put lib under $(dist_bindir) as well.

r=wtc.
Attachment #111894 - Flags: review+

Comment 15

17 years ago
Comment on attachment 111961 [details] [diff] [review]
Update packages-unix

r=wtc.	Thanks!
Attachment #111961 - Flags: review+

Comment 16

17 years ago
Comment on attachment 111894 [details] [diff] [review]
Put lib under $(dist_bindir) as well.

I checked in this patch on the NSPR trunk and
NSPRPUB_PRE_4_2_CLIENT_BRANCH.
Attachment 111961 [details] [diff] has been checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.