Closed
Bug 30532
Opened 25 years ago
Closed 24 years ago
libjpeg.so.62 *still* causing errors when attempting ./mozilla
Categories
(SeaMonkey :: Build Config, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: martin, Assigned: cls)
References
Details
Resolved the proble in M13 by installing the new jpeg libraries as per exisitng problem report. However, M14 and nightly builds complaining: martin@localhost:/ref/mozilla/package > ./mozilla .//run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/ref/mozilla/package LD_LIBRARY_PATH=/ref/mozilla/package SHLIB_PATH=/ref/mozilla/package LIBPATH=/ref/mozilla/package MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= RegSelf Unicode to Big5 converter complete RegSelf Unicode to x-x-big5 converter complete RegSelf Big5 to Unicode converter complete ************************************************** nsNativeComponentLoader: SelfRegisterDll(/ref/mozilla/package/components/libnsjpg.so) Load FAILED with error: libjpeg.so.62: cannot open shared object file: No such file or directory ************************************************** nNCL: registering deferred (0) Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End ProfileManager : GetProfileDir ProfileManager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End WEBSHELL+ = 1 .//run-mozilla.sh: line 29: 26532 Segmentation fault $prog ${1+"$@"} I can get around this error with: ./run-mozilla.sh
Need more details. Which version of glibc are you using? Which compiler was libjpeg.so.62 compiled with? What does 'ldd package/components/libnsjpg.so' return? (And unrelated to the jpeg problem, which shell is /bin/sh?) If I'm not mistaken, the M14 binaries were built on a stock RedHat 6.0 linux distribution which comes with glibc 2.1.1 and uses the egcs 1.1.2 compiler.
In order:
Whats glibc - how do I find its verion?
Used: jpegsrc.v6b.tar.gz
> gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
/ref/mozilla14 > ldd package/components/libnsjpg.so
libjpeg.so.62 => not found
libplds4.so => not found
libplc4.so => not found
libnspr4.so => not found
libpthread.so.0 => /lib/libpthread.so.0 (0x40013000)
libxpcom.so => not found
libnsl.so.1 => /lib/libnsl.so.1 (0x40025000)
libutil.so.1 => /lib/libutil.so.1 (0x4003b000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4003e000)
libdl.so.2 => /lib/libdl.so.2 (0x4004e000)
libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2
(0x40051000)
libm.so.6 => /lib/libm.so.6 (0x40099000)
libc.so.6 => /lib/libc.so.6 (0x400b6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
Using bash
Using SuSE 6.2 - so are half of Europe
Glibc is the C library that you are using. SuSE's rpm based, correct? Try 'rpm -q glibc'. If that doesn't work, `ls -l /lib/libc*' Did you compile libjpeg 6b as a shared library? Did you install it properly (ie, remembered to run ldconfig after installing it)? If libjpeg was installed correctly, it should not be coming up as not found in the ldd results.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 4•25 years ago
|
||
Wasn't there something about a missing symlink to libjpeg.so.62 discussed in bug 26315?
Wrt 26315, I think akkana was just confused because `rpm -qf /usr/lib/libjpeg.so.62` will return 'file /usr/lib/libjpeg.so.62 is not owned by any package'. The symlink is actually created by ldconfig which is usually run by the rpm. Hopefully, this problem will be resolved for the next milestone by having leaf build the mozilla copies of libjpeg, libpng & libz in the official build. Then users can remove the mozilla copies if they already have those versions on their system.
Leaf changed the build to use --without-jpeg which causes mozilla to build its local copy of libjpeg. Are you still seeing this problem with the nightlies?
Build process changed fixed this.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•