Could not find the Mozilla runtime. Topic is solved

[strikematch]

The question:
Why is Pale Moon unable to find the Mozilla runtime, and what environment variables can I set in the wrapper to fix it.

The background:
Trying to run Pale Moon from within a wrapper script results in the Subject line error message. Pale Moon runs fine if executed directly. The shell wrapper exports environment variables needed for sound support. The executable is running under an Ubuntu userspace on a FreeBSD host.

This works (the actual palemoon binary):
/compat/ubuntu/usr/bin/palemoon

This doesn't (the shell wrapper calling the binary):
/compat/ubuntu/bin/palemoon

Relevant lines of the shell wrapper:

Code: Select all

#!/compat/ubuntu/bin/bash
export PALEMOON_PATH="/usr/lib/palemoon/palemoon"
exec -a "$0" "$PALEMOON_PATH" "$@"

Code: Select all

# ls -lhd /usr/bin/palemoon /usr/lib/palemoon/palemoon
lrwxr-xr-x 1 root root   24 Dec 18 14:35 /usr/bin/palemoon -> ../lib/palemoon/palemoon
-rwxr-xr-x 1 root root 179K Dec 18 14:35 /usr/lib/palemoon/palemoon

[Moonchild]

The wrapper needs to make sure that the called executable (argument 0) isn't a symlink. It needs access to the binary file to be able to load XPCOM components that are glued in.

[strikematch]

Thanks for your help, Moonchild.

The wrapper is calling the executable directly. It's effectively doing this:

Code: Select all

/compat/ubuntu/bin/bash -c exec -a /compat/ubuntu/bin/palemoon /usr/lib/palemoon/palemoon "$@"
[interpreter^]                     [wrapper^]                  [palemoon binary^]

Code: Select all

# file /usr/lib/palemoon/palemoon  
/usr/lib/palemoon/palemoon: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=44e0ad8388dd89a1703a243cbe9eb0abb4219b94, stripped

A bit more background:
The palemoon binary is located on the filesystem at /compat/ubuntu/usr/lib/palemoon/palemoon, but the wrapper sees the path as /usr/lib/palemoon/palemoon due to Linux emulation.

Executing /compat/ubuntu/usr/lib/palemoon/palemoon or /compat/ubuntu/usr/bin/palemoon from the command line on the host fires up Pale Moon no problem (but without sound support).

Any ideas?

[Moonchild]

I'm a little fuzzy on Linux's "exec" or how CLI arguments are passed down through it, but the Pale Moon binary literally checks if it can access the called program (command-line argument 0) as a file. If it can't, then it will throw the error shown. So if that is the name of the wrapper, it will fail.

[strikematch]

Thanks again.

To test how the exec command passes arguments to the called executable, I modified the wrapper to do the following:

Code: Select all

# cat /compat/ubuntu/bin/palemoon
#!/compat/ubuntu/bin/bash -x
exec -a "$0" /usr/bin/foo

Code: Select all

# cat /usr/bin/foo
#!/bin/bash -x
ls -lh /compat/ubuntu/bin/palemoon

Code: Select all

# /compat/ubuntu/bin/palemoon
+ exec -a /compat/ubuntu/bin/palemoon /usr/bin/foo
+ ls -lh /compat/ubuntu/bin/palemoon
-r-xr-xr-x 1 root root 372 Feb  3 18:26 /compat/ubuntu/bin/palemoon

/usr/bin/foo, located inside /compat/ubuntu/ like /usr/lib/palemoon/palemoon, is able to stat /compat/ubuntu/bin/palemoon, the calling wrapper. Which seems to indicate the palemoon binary should be able to stat the wrapper, too. AIUI, applications ran from inside the Linux filesystem first look within the Ubuntu chroot, and finally outside of it if a file can't be found. Does that potential redirection sound like it's tripping up the Pale Moon binary's check?

[Moonchild]

I don't know what you mean with "being able to stat"
See my previous reply. It needs to be able to access argument 0 as a file. That is literally the check it does because it needs direct file access to initialize the XPCOM glue. If that is somehow a redirection that requires interpretation, then it will not work.
maybe someone who is fluent in *NIX can explain in more detail why this fails.

[New Tobin Paradigm]

How about not treating UXP applications as ordinary or standard linux programs and utilities. It isn't and never will be.

Also in a system package configuration deps for the binary and runtime are almost never kept together according to bullshit linux standards so invoking it in a fucked up way adds additional complications above a tarball "generic" build. Though I bet you would run into problems with that as well.

Face it, classical mozilla style applications are a beast of a different kind.

[vannilla]

This isn't specific to UXP, if I understood what OP is trying to do.
It will trip up any program using "itself" to find some file, like how XPCOM does to find the runtime.
By "itself" I mean that the program uses the process name taken at runtime, rather than a hardcoded path, to find the necessary resources to initialize itself.
There are only a handful of programs behaving like that, and Pale Moon is probably the most "end user" one, meaning that most people don't even think about this caveat.

While I don't know the exact steps taken by XPCOM, as I don't know where in the code initialization happen, the reason why it does not work should be because the 0th argument passed to the "exec'd" process, that is, the process name, is not the full path to the real Pale Moon binary, but to the wrapper.
Since the wrapper does not have the proper path, the process won't find the runtime.

It is also not caused only by bash: any "exec-like" procedure that does not allow setting the 0th arguments will cause failures in XPCOM (or whatever program you use that does something similar.)

[strikematch]

I don't know what you mean with "being able to stat"

It's *NIX shorthand for being able to find the file (and display detailed information about it, like creation time, permissions, etc.).
https://linux.die.net/man/2/stat

It needs to be able to access argument 0 as a file. That is literally the check it does because it needs direct file access to initialize the XPCOM glue.

That's what modifying the wrapper to call /usr/bin/foo tested. Replace the Pale Moon binary with a script that tries to find the calling wrapper and displays its results: "Unable to locate file" if it can't; or list the file if it can. /usr/bin/foo is able to find the calling wrapper. If /usr/bin/foo can access it, the Pale Moon binary should, too, was my hypothesis. Clearly, that test isn't sufficiently replicating what the binary is doing.

Anyway, thanks for your work on supporting Pale Moon. Although possibly unintended, it's the last remaining browser that still adheres to the ethos of traditional, open source software, where shoving New Great Thing (TM) down end-users throats is considered anathema.

[strikematch]

Your post has completely misunderstood the problem at hand. I laughed a bit while reading it, though.

Face it, classical mozilla style applications are a beast of a different kind.

I don't envy the constant tug-of-war battle the Pale Moon developers are forced to engage in with Mozilla's boneheaded design- and decision-makers. But the work is appreciated.

[strikematch]

This isn't specific to UXP, if I understood what OP is trying to do.

The rest of your post suggests to me you do.

It will trip up any program using "itself" to find some file, like how XPCOM does to find the runtime.
By "itself" I mean that the program uses the process name taken at runtime, rather than a hardcoded path, to find the necessary resources to initialize itself.
...
[T]he reason why it does not work should be because the 0th argument passed to the "exec'd" process, that is, the process name, is not the full path to the real Pale Moon binary, but to the wrapper.
Since the wrapper does not have the proper path, the process won't find the runtime.

This exact setup works for Chromium (using exec within a wrapper, etc., but replacing Chromium's binary with Pale Moon's). I was trying to piggyback off of that solution to get Pale Moon sound support to work. Alas.

Thanks for the help.

[vannilla]

This exact setup works for Chromium (using exec within a wrapper, etc., but replacing Chromium's binary with Pale Moon's). I was trying to piggyback off of that solution to get Pale Moon sound support to work. Alas.

Thanks for the help.

Chromium finds its runtime differently, that's why it works.
Don't ask me what it does, but that's how it is.

Actually, to get your wrapper to work the solution is trivial, but it can get complicated depending on your environment. You might want to look up how to change the process name at exec time.

[strikematch]

Chromium finds its runtime differently, that's why it works.

Right. That's why my OP asked what environment variables I could set in the wrapper to fix it. But as it turns out, that's not possible with Pale Moon.

Actually, to get your wrapper to work the solution is trivial, but it can get complicated depending on your environment. You might want to look up how to change the process name at exec time.

I'll look into it. Thanks.

For anyone that stumbles across this thread wondering where the original setup comes from, it's here, designed to install Chrome or Brave (or any Chrome-based browser, really). It coincidentally also installs a base Ubuntu userspace capable of running Pale Moon, which can be installed using this, which is a "fully-endorsed third-party [build] of Pale Moon for Linux."

chroot into the Ubuntu "jail," add the repos from that link above, install Pale Moon using apt-get, then install Pale Moon 64-bit over-top it.

[New Tobin Paradigm]

Steve is beyond "endorsed 3rd party" staus though. I'd consider him, based on work and dedication, to be as much of a member of the Linux Team as Travis is if only informally.

I am sure Moonchild wouldn't object if he wanted to formalize that status though.

[strikematch]

I'd consider him [...] to be as much of a member of the Linux Team as Travis is[.]

I'm new here, but for what's it's worth he's got my vote for full membership status recognition. It's possible to run Pale Moon from an extracted tarball inside a standard emulators/linux_base-c7 jail, but it requires finding and installing many dependencies manually (and for me resulted in frequent crashes). His packaging work resulted in smooth installation and a stable application.

My only complaint is: I read somewhere on this forum 32-bit support will be dropped soon, but for some reason apt-get only offers the 32-bit version. It's trivial to wget the 64-bit version from his page and install it with dpkg over-top it, but a mystery why that's even necessary.

[Moonchild]

Off-topic:

I am sure Moonchild wouldn't object if he wanted to formalize that status though.

I wouldn't object at all, but I tend to let people come forward themselves if and when they want to.

[New Tobin Paradigm]

As has been written elsewhere we have ended the generic 32bit binary we provide and won't be approving any 32bit 3rd party generic builds either nor any bastardized binary repack BUT we will allow proper from source built system packages that specifically target 32bit distros such as in the case of the debian-based ones Steve is doing which are in no way generic to all of linux.

This serves as an incentive to leave 32bit Linux behind broadly but allows the flexability for distro targeted builds if there is someone dedicated enough to provide not only a package for any specific distro still doing 32bit but also to provide the support to go along with it.

It helps shift our release engineering and support burden from all linux to just those still with active and supported 32bit development. Leaving out old and insecure distros completely.

Of course, individuals can always build whatever the fuck they want for their, and only their, use. We have no plans to drop any older currently used compilers or linux 32bit capability on a build level but it is on a "Best Effort" basis in regards to testing and patches going forward and the community may need to give a care and a hand keeping it up to snuff.

[strikematch]

This serves as an incentive to leave 32bit Linux behind broadly[.]

You misunderstood my "but a mystery why that's even necessary" statement. The logic behind thoughtfully dropping 32-bit support is sound, and I agree with it. The "mystery" is why the Add repository and install manually steps on Steve's site result in 32-bit Pale Moon being installed instead of 64-bit. He does provide 64-bit binaries that can be installed manually afterwards, though.