Fennec Desktop: error while loading shared libraries: libmozsqlite3.so

RESOLVED FIXED in mozilla8

Status

()

Core
Build Config
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: mounir, Assigned: mounir)

Tracking

Trunk
mozilla8
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(2 attachments, 4 obsolete attachments)

(Assignee)

Description

6 years ago
When trying to run fennec on desktop, I got this error:
./fennec: error while loading shared libraries: libmozsqlite3.so: cannot open shared object file: No such file or directory

ldd, as expected shows:
libmozsqlite3.so => not found

But the file is in '.'.

A workaround is to use LD_LIBRARY_PATH=".", though I would expect this to work as well as Firefox Desktop.

My mozconfig is:
ac_add_options --enable-application=mobile
mk_add_options MOZ_MAKE_FLAGS="-s -j5"
ac_add_options --enable-tests
export MOZ_DEBUG_SYMBOLS=1
ac_add_options --enable-debug
ac_add_options --disable-optimize
works for me.

What do the following commands say?
  readelf -d objdir/dist/bin/fennec
  make -C objdir/mobile/app echo-variable-GNU_LD
(Assignee)

Comment 2

6 years ago
(In reply to comment #1)
> What do the following commands say?
>   readelf -d objdir/dist/bin/fennec

readelf returns:
Dynamic section at offset 0x1dd28 contains 35 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libxpcom.so]
 0x0000000000000001 (NEEDED)             Shared library: [libmozalloc.so]
 0x0000000000000001 (NEEDED)             Shared library: [libplds4.so]
 0x0000000000000001 (NEEDED)             Shared library: [libplc4.so]
 0x0000000000000001 (NEEDED)             Shared library: [libnspr4.so]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libxul.so]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
 0x000000000000000c (INIT)               0x401500
 0x000000000000000d (FINI)               0x419308
 0x0000000000000004 (HASH)               0x4002e8
 0x000000006ffffef5 (GNU_HASH)           0x400490
 0x0000000000000005 (STRTAB)             0x400b20
 0x0000000000000006 (SYMTAB)             0x4004f0
 0x000000000000000a (STRSZ)              1060 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x61dfe8
 0x0000000000000002 (PLTRELSZ)           1176 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x401068
 0x0000000000000007 (RELA)               0x401038
 0x0000000000000008 (RELASZ)             48 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x400fc8
 0x000000006fffffff (VERNEEDNUM)         3
 0x000000006ffffff0 (VERSYM)             0x400f44
 0x0000000000000000 (NULL)               0x0

>   make -C objdir/mobile/app echo-variable-GNU_LD

1
Can you try running fennec with LD_DEBUG set to libs and paste the output?
(Assignee)

Comment 4

6 years ago
Created attachment 549955 [details]
LD_DEBUG output

Here is the output of LD_DEBUG=lib ./fennec. It seems that mozsqlite3 has a very specific treatment and is never searched inside the current directory. I hope you will understand why, Mike! :)
Comment on attachment 549955 [details]
LD_DEBUG output

Looks like the problem is that the rpath on fennec is not enough, and there needs to be an rpath on libxul.so as well.

I'd however suggest updating nsBrowserApp.cpp from what is currently in browser/app instead (be aware it requires some changes in Makefile.in)
(Assignee)

Comment 6

6 years ago
Created attachment 550017 [details] [diff] [review]
Attempt
(Assignee)

Comment 7

6 years ago
Created attachment 550021 [details] [diff] [review]
WIP Patch
Attachment #550017 - Attachment is obsolete: true
(Assignee)

Comment 8

6 years ago
Created attachment 550025 [details] [diff] [review]
Patch v1
Assignee: nobody → mounir
Attachment #550021 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #550025 - Flags: review?(mh+mozilla)
(Assignee)

Updated

6 years ago
Whiteboard: [needs review]
(Assignee)

Comment 9

6 years ago
Created attachment 550026 [details] [diff] [review]
Patch v1
Attachment #550025 - Attachment is obsolete: true
Attachment #550025 - Flags: review?(mh+mozilla)
Attachment #550026 - Flags: review?(mh+mozilla)
(Assignee)

Comment 10

6 years ago
Created attachment 550028 [details] [diff] [review]
Patch v1.1

Styling changes.
Attachment #550026 - Attachment is obsolete: true
Attachment #550026 - Flags: review?(mh+mozilla)
Attachment #550028 - Flags: review?(mh+mozilla)
Comment on attachment 550028 [details] [diff] [review]
Patch v1.1

Review of attachment 550028 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/app/Makefile.in
@@ +77,5 @@
>  endif
>  endif #LIBXUL_SDK
>  
> +# This switches $(INSTALL) to copy mode, like $(SYSINSTALL), so things that
> +# shouldn't get 755 perms need $(IFLAGS1) for either way of calling nsinstall.

The reason here is different: it is so that the standalone glue doesn't try to get libxpcom.so from mobile/app. The reason in browser/app is the same now, but the comment is older than that.

r=me with this comment changed.

(for those scared by the nsBrowserApp.cpp changes, it's just a copy of the current browser/app/nsBrowserApp.cpp, and is only used for desktop fennec)
Attachment #550028 - Flags: review?(mh+mozilla) → review+
(In reply to comment #11)

> (for those scared by the nsBrowserApp.cpp changes, it's just a copy of the
> current browser/app/nsBrowserApp.cpp, and is only used for desktop fennec)

And Maemo
(In reply to comment #12)
> And Maemo


Ah true. We may want to disable XPCOMGlueEnablePreload on Maemo.
(Assignee)

Comment 14

6 years ago
(In reply to comment #13)
> (In reply to comment #12)
> > And Maemo
> 
> 
> Ah true. We may want to disable XPCOMGlueEnablePreload on Maemo.

Mark, do you confirm that?
As said on IRC:
A simple #ifdef on whatever distinguishes maemo to avoid enabling preloading might be good ; though maybe preloading would have a positive impact on maemo
We could just land the patch without Maemo #ifdef, and watch the tests. If a problem occurs, you could land a followup with some #ifdef MOZ_PLATFORM_MAEMO in the right places.
(Assignee)

Comment 17

6 years ago
(In reply to comment #16)
> We could just land the patch without Maemo #ifdef, and watch the tests. If a
> problem occurs, you could land a followup with some #ifdef
> MOZ_PLATFORM_MAEMO in the right places.

Pushed then :)
Flags: in-testsuite-
Whiteboard: [needs review] → [inbound]
(In reply to comment #17)
> Pushed then :)

You didn't change the comment for NSDISTMODE...
(Assignee)

Comment 19

6 years ago
OUPS! I just pushed a follow-up to fix that.
Sorry :(
http://hg.mozilla.org/mozilla-central/rev/144add433e72
http://hg.mozilla.org/mozilla-central/rev/cfb447e2f21f
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Not sure if it is expected or not, but I do see ~100ms Ts regression on Maemo when this patch, and a few others from m-i, landed on m-c.

The regression isn't horrible, but maybe we should try to disable preloading, as Mike suggested. What does preloading do exactly?
(In reply to Mark Finkle (:mfinkle) from comment #21)
> Not sure if it is expected or not, but I do see ~100ms Ts regression on
> Maemo when this patch, and a few others from m-i, landed on m-c.
> 
> The regression isn't horrible, but maybe we should try to disable
> preloading, as Mike suggested. What does preloading do exactly?

It reads all the libraries listed in dependentlibs.list before dlopen()ing them.
On hard drives, that makes a huge difference, but on flash, it ranges from limited improvement to slower.
(Assignee)

Comment 23

6 years ago
Mark, if you open a follow-up and assign the bug to me, I can write the patch ;)
(In reply to Mounir Lamouri (:volkmar) from comment #23)
> Mark, if you open a follow-up and assign the bug to me, I can write the
> patch ;)

Filed bug 677146
Depends on: 677146
Depends on: 677247
You need to log in before you can comment on or make changes to this bug.