123918 - TestGtkEmbed fails to launch with shared libraries error:

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Tracy Walker [:tracy]]

seen on linux TestGtkEmbed build 2002-02-06-09-trunk

-Install the build and attempt to launch
the follow error appears on the console:

./TestGtkEmbed: error while loading shared libraries: libgtkembedmoz.so: cannot
open shared object file: No such file or directory

Comment 1

[Daniel (Leaf) Nunes]

i assume there's no .so file in there... is that true of all of this morning's
linux directories?

Comment 2

[Tracy Walker [:tracy]]

the libgtkembedmoz.so file is present in the install directory.

Comment 3

[Daniel (Leaf) Nunes]

the embedding package from
http://ftp.mozilla.org/pub/mozilla/nightly/2002-02-06-11-trunk/
worksforme.

Can you post a directory listing where it isn't working for you ("ls -la *"
should do the trick).

Comment 4

[Daniel (Leaf) Nunes]

(i just noticed, clicking on links causes a segfault, but loading in the urlbar
seems to work fine)

Comment 5

[Tracy Walker [:tracy]]

drwxr-xr-x    6 footprin games        4096 Feb  6 12:13 .
drwxr-xr-x    3 footprin games        4096 Feb  6 12:13 ..
-rwxr-xr-x    1 footprin games       35519 Feb  6 09:55 TestGtkEmbed
drwxr-xr-x    2 footprin games        4096 Feb  6 09:55 chrome
-rw-r--r--    1 footprin games      283860 Feb  6 12:14 component.reg
drwxr-xr-x    2 footprin games        4096 Feb  6 12:13 components
drwxr-xr-x    3 footprin games        4096 Feb  6 09:55 defaults
-rw-r--r--    1 footprin games     6550050 Feb  6 09:55
embed-i686-pc-linux-gnu.tar.gz
-rwxr-xr-x    1 footprin games      220331 Feb  6 09:55 libgkgfx.so
-rwxr-xr-x    1 footprin games      143783 Feb  6 09:55 libgtkembedmoz.so
-rwxr-xr-x    1 footprin games       23032 Feb  6 09:55 libgtksuperwin.so
-rwxr-xr-x    1 footprin games      497793 Feb  6 09:55 libmozjs.so
-rwxr-xr-x    1 footprin games       59238 Feb  6 09:55 libmozz.so
-rwxr-xr-x    1 footprin games      220316 Feb  6 09:55 libnspr4.so
-rwxr-xr-x    1 footprin games       20172 Feb  6 09:55 libplc4.so
-rwxr-xr-x    1 footprin games       13034 Feb  6 09:55 libplds4.so
-rwxr-xr-x    1 footprin games     1314871 Feb  6 09:55 libxpcom.so
drwxr-xr-x    5 footprin games        4096 Feb  6 09:55 res
-rwxr-xr-x    1 footprin games        9980 Feb  6 09:55 run-mozilla.sh

Comment 6

[Adam Lock]

Dumb question, but are you typing "./run-mozilla.sh ./TestGtkEmbed" or just
"./TestGtkEmbed"? The initial description is unclear.

Comment 7

[Tracy Walker [:tracy]]

./TestGtkEmbed...doing this by script and by hand.  

Comment 8

[Tracy Walker [:tracy]]

this is what happens when I try the other startup method

> ./run-mozilla.sh TestGtkEmbed 
new_gtk_browser
	menu bar
	tool bar
	location bar
	status bar
**************************************************
nsNativeComponentLoader:
SelfRegisterDll(/u/twalker/embed/bin/components/libpipnss.so) Load FAILED with
error: libsmime3.so: cannot open shared object file: No such file or directory
**************************************************
**************************************************
nsNativeComponentLoader:
SelfRegisterDll(/u/twalker/embed/bin/components/libxpconnect.so) Load FAILED
with error: /u/twalker/embed/bin/components/libxpconnect.so: undefined symbol:
JS_PropertyStub
**************************************************


Oh no!  TestGtkEmbed just dumped a core file.

Do you want to debug this ? You need a lot of memory for this, so watch out ?
[y/n] 

Comment 9

[Adam Lock]

I downloaded 2002-02-06-11-trunk/
embed-i686-pc-linux-gnu.tar.gz and it worksforme whether I run it via the script
or directly. I get a complaint from libpipnss.so not being able to load
libsoftokn3.so but it runs anyway. I don't see any problems in libxpconnect.so.
Link clicking works too.

Comment 10

[Adam Lock]

Attachment: My directory listing

This is the output from doing ls -lR on my embed download.

Comment 11

[Adam Lock]

Correction, I downloaded 2002-02-06-09-trunk/embed-i686-pc-linux-gnu.tar.gz but
it worked for me anyway.

Tracy do you have any other Mozilla/embedding dists in your LD_LIBRARY_PATH
environment variable or in /etc/ld.so.conf?

Comment 12

[Tracy Walker [:tracy]]

I don't know how to check the LD_LIBRARY_PATH.  This is what is in 
/etc/ld.so.conf:

/usr/X11R6/lib
/usr/i486-linux-libc5/lib
/usr/gcc295/lib

Comment 13

[Adam Lock]

In bash/ksh/sh, just type 'set' and it lists all the environment variables. In
csh/tcsh type 'setenv'.

The errors you are seeing suggest that there is some kind of problem resolving
shared libraries so the settings for LD_LIBRARY_PATH or /etc/ld.so.conf might be
causing this. If had other copies of Mozilla/Gecko in in the library path it
might be they were getting picked up instead of the ones in the current directory.

That is also why I asked about whether you running TestGtkEmbed directly or via
run-mozilla.sh. The script ensures the dist directory (and plugins/) are in the
path to be resolved. 

Comment 14

[Adam Lock]

Something interesting I've discovered. Type "about:" as the URL after running as
"./TestGtkEmbed" and as "./run-mozilla.sh ./TestGtkEmbed". On my box, the former
says 0.9.4 and the latter says 0.9.8+!

So it looks as though TestGtkEmbed will use the first copy of Mozilla libs it
finds in its path. The run-mozilla.sh script sets the LD_LIBRARY_PATH
environment variable so it looks in the current dir first to find the libs and
that prevents the problem.

Comment 15

[Kai Engert [:KaiE:]]

Yesterday we switched to NSS 3.4, which introduced 4 new shared libraries on
Unix systems. One of them is libsmime3.so.

It should be contained in the same directory as TestGtkEmbed. I suspect we have
a problem with packaging of the embedded distribution. I created updates to the
packaging list for the Mozilla installer (in the patch in bug 116334), did I
miss something for the embedded package?

Comment 16

[Adam Lock]

The embedding packages are in mozilla/embedding/config.

I am thinking that perhaps the missing shared libs are causing the psm resolve
to some old Mozilla shared lib somewhere else in the path causing strange problems.

Comment 17

[Brian Ryner (not reading)]

Yes, this definitely sounds like another copy of Mozilla is present in the path
and/or TestGtkEmbed is being run incorrectly.  The correct way to run it, so
that it uses the correct versions of all libraries, is "./run-mozilla.sh
./TestGtkEmbed".  (perhaps we should make a small shell script for this?)

Comment 18

[Adam Lock]

This is definitely fallout from recent psm changes. If I delete libpip* from
components & component.ref and re-run then I don't see any problems at all. My
guess is the missing files are totally horking something (e.g. building of
component.reg the first time around) and this causes subsequent runs to be busted.

The solution is probably to patch embedding/config's manifests with the same
changes that went into the Mozilla package files.

Comment 19

[Adam Lock]

I guess the changes made to the Mozilla packages in attachment 67193 [details] [diff] [review] will also
have to be added to the embedding manifests in mozilla/embedding/config.

I will make the patches, but Kai can you review they are correct?

Comment 20

[Kai Engert [:KaiE:]]

Attachment: Suggested fix

This patch should fix it, but I have never built an embedding package, can you
help me to test it?

Comment 21

[Adam Lock]

Attachment: patch

Comment 22

[Adam Lock]

Comment on attachment 68388 [details] [diff] [review]
Suggested fix

Kai yours an my patch are the same so r=adamlock.

I tested my patch on "intrepid.mcom.com" and it fixed the problem

Comment 23

[Alec Flett]

Comment on attachment 68388 [details] [diff] [review]
Suggested fix

ack, look at all these dlls we're adding to the embedding client! smime3? There
must be a better way...

Comment 24

[Adam Lock]

Yes definitely! Embedding should be a way to demonstrate how modular Mozilla is
so we should try and avoid any uncessary dependencies in future. 

Fix is checked in now.

Comment 25

[Adam Lock]

Fixed

Comment 26

[Kai Engert [:KaiE:]]

CC'ing Wan-Tah, maybe you want to answer Alec's comment?

However, I guess Wan-Teh's comment at
http://bugzilla.mozilla.org/show_bug.cgi?id=118833#c12
should contain the answer already.

I have not yet asked, could we have a build mode for NSS, where
there is only one DLL for all parts of NSS?

Comment 27

[Tracy Walker [:tracy]]

verified fixed with linux commercial embed build from 2002-02-07-14

Comment 28

[Wan-Teh Chang]

These new NSS dlls used to be part of pipnss.dll.  The
code bloat should be partially compensated by a smaller
pipnss.dll.

nss3.dll and softokn3.dll constitute the core NSS library.

ssl3.dll is the SSL library.  It requires nss3.dll.

smime3.dll is the S/MIME library.  It requires nss3.dll.

ssl3.dll and smime3.dll can be used independent of each other.
If you only need SSL, you just need ssl3.dll, nss3.dll, and
softokn3.dll.  However, I suspect pipnss.dll may require
smime3.dll.