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.
Adding Chris to the interest list as he's a build/config wizard.
Priority: -- → P3
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
Thanks wtc, we'll give this a try! If possible, can we keep the bug open until we get a chance to report back?
Is this still an issue?
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → Future
*** Bug 183822 has been marked as a duplicate of this bug. ***
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
Is this only on the Sun C compiler (Sun One Studio now) or does this work for gcc as well?
This is a linker feature and is independent of the compiler.
wtc: Dumb question: What happens with your patch if someone compiles Mozilla as 64bit (=sparcv9) application ? Will that hack/feature then be disabled automagically ?
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
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 on attachment 111894 [details] [diff] [review] Put lib under $(dist_bindir) as well. r=wtc.
Attachment #111894 - Flags: review+
Comment on attachment 111961 [details] [diff] [review] Update packages-unix r=wtc. Thanks!
Attachment #111961 - Flags: review+
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
You need to log in before you can comment on or make changes to this bug.