libjpeg.so.62 *still* causing errors when attempting ./mozilla

RESOLVED FIXED

Status

SeaMonkey
Build Config
P3
normal
RESOLVED FIXED
18 years ago
13 years ago

People

(Reporter: martin, Assigned: cls)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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
(Assignee)

Comment 1

18 years ago
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.  
(Reporter)

Comment 2

18 years ago
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
(Assignee)

Comment 3

18 years ago
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

18 years ago
Wasn't there something about a missing symlink to libjpeg.so.62 discussed in 
bug 26315?
(Assignee)

Comment 5

18 years ago
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.

Comment 6

18 years ago
*** Bug 29765 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 7

18 years ago
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?
(Assignee)

Comment 8

18 years ago
Build process changed fixed this.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 9

18 years ago
M15 seems to have fixed this.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.