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

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Alex Vincent [:WeirdAl]]

Attachment: 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.

Comment 1

[Alex Vincent [:WeirdAl]]

Attachment: ldd -d -r dist/bin/xpcshell

Comment 2

[Alex Vincent [:WeirdAl]]

<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.

Comment 3

[Mike Hommey [:glandium]]

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

[Martin Stránský [:stransky] (ni? me)]

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

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 6

[Mike Hommey [:glandium]]

(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

[Martin Stránský [:stransky] (ni? me)]

(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 ;-)

Comment 8

[Alex Vincent [:WeirdAl]]

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

Comment 9

[Martin Stránský [:stransky] (ni? me)]

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

[Takanori MATSUURA]

Is this something like bug 686434?

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Yes, seems so, although Alex haven't told us how he builds the code.

Comment 12

[Alex Vincent [:WeirdAl]]

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

Comment 13

[Alex Vincent [:WeirdAl]]

Also, I typically blow away my objdir every time, so it's a clobber build, not incremental.

Comment 14

[Mike Hommey [:glandium]]

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

[Takanori MATSUURA]

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.

Comment 16

[Mike Hommey [:glandium]]

(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

[Martin Stránský [:stransky] (ni? me)]

(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).

Comment 18

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.