dist/bin/xpcshell: symbol lookup error: dist/bin/xpcshell: undefined symbol: JSVAL_NULL

NEW
Unassigned

Status

()

Core
XPConnect
6 years ago
5 years ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

({regression})

Trunk
x86_64
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 559662 [details]
mozconfig

For some reason, using this mozconfig on my Fedora Linux machine, xpcshell will not start.  Instead, I get the error in the summary.

This does NOT happen with Aurora code.  So it's a relatively recent regression.
(Reporter)

Comment 1

6 years ago
Created attachment 559663 [details]
ldd -d -r dist/bin/xpcshell
(Reporter)

Comment 2

6 years ago
<sfink> does it magically start working if you set LD_LIBRARY_PATH to .../dist/bin before running?

Yes, it does.

Another note:  this didn't affect me on my Windows or Mac systems.
xpcshell is not supposed to run without run-mozilla.sh, which sets LD_LIBRARY_PATH appropriately. I don't think anything changed in that regard. Are you sure you were actually using the libs from dist/bin before?

Comment 4

6 years ago
It fails as a part of make install (when building xulrunner as rpm package). set up LD_LIBRARY_PATH does not help me...investigating.

Comment 5

6 years ago
It fails because xpcshell has a rpath to /usr/lib/xulrunner-2 and /usr/lib64/xulrunner-2/libmozjs.so there does not contain JSVAL_NULL. 

So the new xpcshell still runs with old (installed) libraries when system xulrunner is installed.
(In reply to Martin Stránský from comment #5)
> It fails because xpcshell has a rpath to /usr/lib/xulrunner-2 and
> /usr/lib64/xulrunner-2/libmozjs.so there does not contain JSVAL_NULL. 
> 
> So the new xpcshell still runs with old (installed) libraries when system
> xulrunner is installed.

For you it fails because of that. But we don't set an rpath in our build system. So Alex's problem is different (though the cause is similar: his build must be using some other libmozjs.so)

Comment 7

6 years ago
(In reply to Mike Hommey [:glandium] from comment #6)
> For you it fails because of that. But we don't set an rpath in our build
> system. So Alex's problem is different (though the cause is similar: his
> build must be using some other libmozjs.so)

Alex says he runs Fedora like me so I guess it's the same problem ;-)
(Reporter)

Comment 8

6 years ago
FWIW, I run 64-bit Fedora, which for all I know may be a factor here.

Comment 9

6 years ago
libmozjs.so => /usr/lib64/xulrunner-2/libmozjs.so (0x00007f0e5d710000)

It looks like your xpcshell has a rpath to /usr/lib64/xulrunner-2 which is a system-wide xulrunner on Fedora. In Fedora xulrunner rpm it's caused by 

export LDFLAGS="-Wl,-rpath,%{mozappdir}"

line in xulrunner.spec (or firefox.spec).

btw. the "regression" here is caused by new symbols in libmozjs.so, which are not present in old (system-wide) libmozjs.so.

Comment 10

6 years ago
Is this something like bug 686434?

Comment 11

6 years ago
Yes, seems so, although Alex haven't told us how he builds the code.
(Reporter)

Comment 12

6 years ago
I don't do anything special.  I attached my mozconfig earlier.  Basically, what I do is the following:

export MOZCONFIG=(path to mozconfig)
cat $MOZCONFIG # So I can be sure I got it right
cd trunk/mozilla
hg pull -u
make -f client.mk configure
cd ../fx-debug # in this case; I usually build optimized instead
make -j40 -s
dist/bin/xpcshell
(Reporter)

Comment 13

6 years ago
Also, I typically blow away my objdir every time, so it's a clobber build, not incremental.
I hear that fedora's xulrunner package ships a /etc/ld.so.conf.d/xulrunner-64.conf file that makes ld.so search in /usr/lib64/xulrunner-1.9.2 for libs... that would explain your problem. In all cases, xpcshell should be run through run-mozilla.sh or some other script that sets the environment correctly.

Comment 15

6 years ago
During the build stage, newly generated binaries should search shared objects under dist/ first.

BTW, does "-j40" works fine?
I have never tested -j40. And I have never got this kind of error with -j2 or -j4 on Fedora.
(In reply to Takanori MATSUURA from comment #15)
> During the build stage, newly generated binaries should search shared
> objects under dist/ first.

All calls to binaries during the build should already be properly wrapped. But there could be a few missing, I don't know.

Comment 17

6 years ago
(In reply to Mike Hommey [:glandium] from comment #14)
> I hear that fedora's xulrunner package ships a
> /etc/ld.so.conf.d/xulrunner-64.conf file that makes ld.so search in
> /usr/lib64/xulrunner-1.9.2 for libs... that would explain your problem. In
> all cases, xpcshell should be run through run-mozilla.sh or some other
> script that sets the environment correctly.

Yes, that's correct, we ship that file on Fedora, mostly for historical reasons (gtkmozembed apps).
You need to log in before you can comment on or make changes to this bug.