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

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[martin]

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

Comment 1

[cls]

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.  

Comment 2

[martin]

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

Comment 3

[cls]

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.

Comment 4

[Richard Zach]

Wasn't there something about a missing symlink to libjpeg.so.62 discussed in 
bug 26315?

Comment 5

[cls]

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

[Sebastian Späth]

*** Bug 29765 has been marked as a duplicate of this bug. ***

Comment 7

[cls]

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?

Comment 8

[cls]

Build process changed fixed this.

Comment 9

[martin]

M15 seems to have fixed this.