Closed
Bug 542053
Opened 14 years ago
Closed 14 years ago
OOPP do not work in XR builds
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a4
People
(Reporter: dougt, Assigned: cjones)
References
Details
Attachments
(2 files)
2.10 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
6.70 KB,
patch
|
benjamin
:
review+
christian
:
approval1.9.2.4+
|
Details | Diff | Splinter Review |
http://mxr.mozilla.org/mozilla-central/source/ipc/glue/GeckoChildProcessHost.cpp#182 We current assume that the mozilla-runtime lives next to the executable (eg. firefox-bin). There are some configurations, like fennec, that use separate directory for their application and the mozilla runtime stuff. For this case, we want to do something like look up the XRE location using the directory service.
Reporter | ||
Comment 1•14 years ago
|
||
this isn't a complete solution because LD_LIBRARY_PATH still needs to be set in order to avoid missing symbols: /home/user/fennec/xulrunner/mozilla-runtime: symbol lookup error: /home/user/fennec/xulrunner/mozilla-runtime: undefined symbol: XRE_StringToChildProcessType
Reporter | ||
Updated•14 years ago
|
Attachment #423400 -
Attachment is patch: true
Attachment #423400 -
Attachment mime type: application/octet-stream → text/plain
Reporter | ||
Updated•14 years ago
|
Attachment #423400 -
Flags: review?(benjamin)
Updated•14 years ago
|
Attachment #423400 -
Flags: review?(benjamin) → review+
Updated•14 years ago
|
Updated•14 years ago
|
Assignee: nobody → dougt
Target Milestone: --- → mozilla1.9.3a4
Comment 3•14 years ago
|
||
Doug, are you going to implement the other half of this bug (setting up LD_LIBRARY_PATH programmatically)?
Comment 4•14 years ago
|
||
Wouldn't a $ORIGIN rpath be better ?
Comment 5•14 years ago
|
||
I really don't want to muck about changing rpath stuff on the stable branch: the OOPP code is planned to backport to 1.9.2/Fx3.6. I would welcome an investigation of using ORIGIN on trunk for 1.9.3, if we can rely on a new-enough ld.so... when was support for origin added to ld.so?
Comment 6•14 years ago
|
||
(In reply to comment #5) > I really don't want to muck about changing rpath stuff on the stable branch: > the OOPP code is planned to backport to 1.9.2/Fx3.6. I would welcome an > investigation of using ORIGIN on trunk for 1.9.3, if we can rely on a > new-enough ld.so... when was support for origin added to ld.so? According to glibc's git, version 2.0.96, released in 1998.
Comment 7•14 years ago
|
||
cjones, can you hack in the environment-variable bit? This is going to bite Linux distros for 3.6.4 unless they disable OOPP, so a hack which we can land today is better than a perfect solution.
Assignee: dougt → jones.chris.g
blocking1.9.2: --- → ?
Assignee | ||
Comment 8•14 years ago
|
||
Not tested in a xulrunner build, but it'd stomping my existing LD_LIBRARY_PATH with the right thing for my normal build.
Attachment #438148 -
Flags: review?(benjamin)
Comment 9•14 years ago
|
||
Comment on attachment 438148 [details] [diff] [review] Set LD_LIBRARY_PATH=[GRE dir] for mozilla-runtime Looks good. Let's get this landed in m-c and mh/wrosenauer can I get one of you to verify?
Attachment #438148 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 10•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/402dff168b49
Whiteboard: [land-lorentz]
Comment 11•14 years ago
|
||
I'm a bit confused. I've built from 1.9.2 branch today before and created testpackages with usual xulrunner/firefox split and w/o doing anything special I got a working mozilla-runtime based Flash applet. Not quite sure why it just works for me currently.
Whiteboard: [land-lorentz]
Assignee | ||
Updated•14 years ago
|
Attachment #438148 -
Flags: approval1.9.2.4?
Comment 12•14 years ago
|
||
Based on comment 11 and the red builds after checkin, I think we'll wait for this to bake a little longer!
blocking1.9.2: ? → needed
status1.9.2:
--- → wanted
Assignee | ||
Comment 13•14 years ago
|
||
The red is just a consequence of needless platform-specific fragmentation in some of this code, and me thinking this patch was small enough not to tryserver. No cause for alarm. Followups http://hg.mozilla.org/mozilla-central/rev/c11e93ca14b6 http://hg.mozilla.org/mozilla-central/rev/88a9ffdc4fea
Comment 14•14 years ago
|
||
(In reply to comment #8) > Created an attachment (id=438148) [details] > Set LD_LIBRARY_PATH=[GRE dir] for mozilla-runtime You should keep whatever was set before and append :$GRE_DIR if there was a value. If for $whatever reason the previous LD_LIBRARY_PATH was necessary to get some required libraries, it won't work.
Comment 15•14 years ago
|
||
(In reply to comment #11) > I'm a bit confused. I've built from 1.9.2 branch today before and created > testpackages with usual xulrunner/firefox split and w/o doing anything special > I got a working mozilla-runtime based Flash applet. Not quite sure why it just > works for me currently. Are you using run-mozilla.sh ? In that case, LD_LIBRARY_PATH is already set.
Comment 16•14 years ago
|
||
(In reply to comment #15) > (In reply to comment #11) > > I'm a bit confused. I've built from 1.9.2 branch today before and created > > testpackages with usual xulrunner/firefox split and w/o doing anything special > > I got a working mozilla-runtime based Flash applet. Not quite sure why it just > > works for me currently. > > Are you using run-mozilla.sh ? In that case, LD_LIBRARY_PATH is already set. No, I'm using xulrunner-stub without any environment LD hacks. But I guess it works for me because I set -rpath for all the xulrunner components (including mozilla-runtime) to the GRE dir. I do that since ages and it should be fine since all stuff from one GRE should first depend on itself.
Assignee | ||
Comment 17•14 years ago
|
||
(In reply to comment #14) > (In reply to comment #8) > > Created an attachment (id=438148) [details] [details] > > Set LD_LIBRARY_PATH=[GRE dir] for mozilla-runtime > > You should keep whatever was set before and append :$GRE_DIR if there was a > value. No. If you're referring to release builds, please supply a compelling use-case that applies to people other than Mozilla/Gecko/xulrunner developers for non-release builds.
Comment 18•14 years ago
|
||
(In reply to comment #17) > No. If you're referring to release builds, please supply a compelling use-case > that applies to people other than Mozilla/Gecko/xulrunner developers for > non-release builds. Some Linux users have a tendency to have weird setups, and I wouldn't be surprised some of them have some libraries in some weird directory they put in LD_LIBRARY_PATH. Some of these libraries could very well be dependencies of the XRE. I, for one, though not in recent days, have sometimes used a $HOME/lib directory to install newer versions of some libraries. If the XRE is using these, you may want mozilla-runtime to do so as well.
Comment 20•14 years ago
|
||
This will never get branch approval until it's marked FIXED...
Status: NEW → RESOLVED
Closed: 14 years ago
Component: Plug-ins → IPC
QA Contact: plugins → ipc
Resolution: --- → FIXED
Comment 21•14 years ago
|
||
Comment on attachment 438148 [details] [diff] [review] Set LD_LIBRARY_PATH=[GRE dir] for mozilla-runtime a=LegNeato for 1.9.2.4
Attachment #438148 -
Flags: approval1.9.2.4? → approval1.9.2.4+
Assignee | ||
Comment 22•14 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a48af4f6a99e
Comment 23•14 years ago
|
||
So, I guess I'll have to file a new bug for comment 18...
Comment 24•14 years ago
|
||
FWIW, a similar issue was reported in bug 434997 comment 5, but we don't seem to have a bug report on that. It would be nice to sort something out to make it easier to run child processes against debug libraries, though. I wonder whether -Wl,-rpath,'$ORIGIN' would be a sensible solution.
Comment 25•14 years ago
|
||
(In reply to comment #24) > I wonder whether -Wl,-rpath,'$ORIGIN' would be a sensible solution. It would just do the right thing, wouldn't require the patch from this bug, and would handle LD_LIBRARY_PATH properly. And cf. comment 6, it's been supported for ages.
Comment 27•14 years ago
|
||
bug 552864 covers ditching the wrapper scripts in favor of -rpath=$ORIGIN.
You need to log in
before you can comment on or make changes to this bug.
Description
•