the M11 solaris 7 binaries are all linked with libucb.so.1. many solaris installations do not install this library. it's even recommended in the solaris2 FAQ that newly compiled programs should not use this (buggy) library, but instead should use "native" solaris2/SYSV system calls.
Dan, can you take this one? Cc'ing mcafee, he's solaris-savvy too.
lxr didn't turn up any obvious uses of -lucb .. ?
Mike, what browser did you use to submit this bug? Which version?
netscape communicator 4.6 running on solaris 7
[richb - 4/20/00] This is definitely still true for Mozilla built on Solaris with Gnu compilers. It's probably dependent on where ./configure is getting ld from. ie: checking for ld... (cached) /usr/ucb/ld It would be worth trying to build Mozilla with the Gnu compilers with /usr/ccs/bin on your PATH before (or instead of) /usr/ucb. Note also that the Solaris Mozilla builds generated with the Sun Workshop 5.0 compilers do not have this problem.
Interesting. I was never able to reproduce this problem, and it was probably because my PATH is set differently than the client build accounts. So perhaps the right fix is to have configure.in notice when it's running on Solaris and forcibly eject /usr/ucb from it's PATH before doing any tests. Thoughts?
[richb - 4/24/00] > So perhaps the right fix is to have configure.in notice when it's running on > Solaris and forcibly eject /usr/ucb from it's PATH before doing any tests. Or alternatively, automatically force ld to be obtained from /usr/ccs/bin for the Solaris platform.
Reassigning Solaris-specific bugs to richb.
richb: doesn't GNU have its own "ld"? If so, it might be installed in /usr/local or somewhere else. If that's the case, then forcibly using /usr/ccs/bin/ld wouldn't be ideal. I thought GNU had its own ld, but not sure. Maybe somebody knows? (Dan? Some Sun person?) If other ld's are valid, then I think it's a good idea to remove /usr/ucb from the path during configure time, so that it's not available for linking.
[richb - 5/29/00] George, I've asked Sherry Shen to investigate this one, but I can add in this: 1/ The /pkg hierarchy that we get from pkg.eng.sun.com, includes a gnu subdirectory, and there is no ld in the /pkg/gnu/bin directory. 2/ The nightly builds that Kevin Lee is doing in /net/tuffy/export/home/MOZILLA/ make sure that ld is picked up from /usr/ccs/bin and there is no libucb.so.1 dynamically linked in. I think the right fix here is for configure to check if it's running on Solaris, and if yes, force ld to be obtained from /usr/ccs/bin.
Reassigning to Sherry Shen.
I studied this problem and found that (1) The libucb.so.1 is linked in old binaries (M11), but not on new ones (M15) for Solaris from the web download in http://www.mozilla.org/projects/seamonkey/release-notes/ (2) The libucb.so.1 is not linked in the M15 binaries of my own build with use of GNU compiler on Solaris since I did not have /usr/ucb in my PATH and /usr/ccs/bin/ld is used. When I added /usr/ucb in my PATH before /usr/ccs/bin and built M15 again, I do see /usr/ucb/ld is used and libucb.so.1 is linked in. (3) The mozilla/configure picked first ld in the $PATH during the build configure. I modified it to ignore /usr/ucb when picking up ld for Solaris, which did not solve the problem even though /usr/ccs/bin/ld is picked in top level build configure. I found several some other configure and make files below the top level pick their own ld from $PATH. (4) This problem did not appear on Linux since it uses /usr/bin/ld. Hence, I think that we should tell the builder not to put /usr/ucb in the PATH for Solaris in order to avoid the linkage of the libucb.so.1. I will leave this bug as WONTFIX here.