Problem with portables (bash related?)

[mikeslr]

Hi all,

Vague recollection of having experienced the following in some other context but passed it off as a fluke or was distracted before posting. See Edit below --checking other portables was a thought which bubbled-up thru the vagueness. Seeing if portables would run under fossapup would have been one of the first things I would have explored after deploying fossapup.

Using Iron-portable as an example, Mike Walsh structures the portables he publishes so that within a folder named Iron-portable there's another folder named, for example, iron64. Iron64 contains all the binaries, libs and other essential files, including a bash-script (wrapper) named iron-pup. Iron-pup sets up the conditions needed to run iron under Puppies [such as no-sandbox] then calls the actual binary named 'chromium'. Within the iron-portable folder but exterior to the iron64 folder is a bash-script named LAUNCH which calls the iron-pup wrapper. The system is designed to enable starting the application by file-browsing to and clicking the LAUNCH bash-script, saving you from having to browse into the iron64 folder and find iron-pup among its many files. You could by-pass the LAUNCH script and start the application by clicking the iron-pup wrapper. This system enables portables to be added to the Start-Menu by including a bash-script 'on the path' calling either iron-pup or LAUNCHER and identifying the bash-script on the path as the executable in /usr/share/applications/....desktop's Exec= argument.

Under fossapup, neither clicking nor double-clicking either iron-pup or LAUNCH does anything. On the other hand, Right-Clicking either and selection "run in terminal" starts the application. Both iron-pup and LAUNCH were script created in puppies other than fossa. Hypothesizing that might have had some effect, I recreated the scripts in fossapup. Those also did nothing. So, there does not appear to be anything wrong with either the portable-application or bash-scripts.

Edit: Just checked Mike Walsh's other portables: google-chrome, opera, vivaldi. Same problem. On the other hand, Brave-portable, lossless-cut, and all mozilla-based and palemoon portables do start by clicking their respective 'wrappers'. Brave's wrapper configures it to run as spot; but lossless-cut's doesn't.

So, it doesn't appear to be a generic 'bash' problem leaving me without any clue as to what's going wrong.

[williams2]

Does it work if you type something like this in a text terminal (the console icon):

Code: Select all

# /opt/Iron-portable/LAUNCH
bash: /opt/Iron-portable/LAUNCH: No such file or directory
#

using the correct path, of course.
If it doesn't start, there might be helpful error messages.

What happens if you try (using the correct path):

Code: Select all

rox /opt/Iron-portable/LAUNCH

rox name-of-file will work as if you clicked the file in a rox window.
Does it start?
If it doesn't start, are there any error messages?

What might be happening is the environment is slightly different when the file is clicked, as opposed to running in a terminal.

You can edit the .desktop file in /usr/share/applications/ and change
Terminal=false
to
Terminal=true
but that might not be what you want to do.

[mikeslr]

Thanks, williams2, for taking an interest. Further exploration produced curious results.

I first tried the terminal commands you suggested, which produced the following results:

root# bash: /mnt/home/Pup-Apps/Iron-portable/LAUNCH
bash: bash:: command not found
root#

root# rox /mnt/home/Pup-Apps/Iron-portable/LAUNCH
root#
The above displayed immediately.

I had in storage a 'menu-pet' used under Xenialpup64 and Bionicpup64: Basically a bash-script, an icon and this desktop file in /usr/share/applications tying them together:

[Desktop Entry]
Encoding=UTF-8
Name=Iron64-portable
Icon=/root/my-applications/bin/iron.png
Comment=iron web browser
Exec=/root/my-applications/bin/iron
Terminal=false
Type=Application
Categories=X-Internet
GenericName=iron web browser

Believing it wouldn't work, I hadn't installed it. But upon your suggestion I did, editing the desktop file's Terminal argument to read:
Terminal=true

As I suspected, clicking the bash command in /my-applications/bin did nothing. Nor did it start via the menu. But clicking the desktop file in /usr/share/applications started the applications.

P.S. Just thought about adding it to a JWM-panel Launcher. Did. That didn't start the applications. But when dragged to the desktop iron-portable.desktop would.

Also curious. Contrary to my guess, in both instances when iron was started via the desktop file, then closed, the terminal also closed. I would have expected it to stay open. [Well, I really didn't have any experience to support that guess; just the assumption that when started that way first the terminal would open, start the application which, on closing, would still leave the terminal open. Even I know the hazards of making assumptions in the absence of evidence.].

Further thought. I installed lxterminal and set it as default almost immediately after deploying fossapup. But the terminal which opened in every instance above was the built-in urxvt. [FWIW, right-clicking an empty space and selecting Window>terminal here opens lxterminal].

[williams2]

Yes, curious results, which can be caused by differences in the environment.

bash, sh, and ash run in slightly different environments.
and applications started by rox, eg. right click run in terminal, may have a slightly different environment.

Typing set will show you the environment.

I tried iron-portable. It does start by right clicking and Run in Terminal, but not by running LAUNCH in a term

Running LAUNCH in a term prints this error message:
/opt/Iron-portable/iron64/chrome: error while loading shared libraries: libffi.so.6: cannot open shared object file: No such file or directory

So I put this in /opt/Iron-portable/iron64/iron-pup:

Code: Select all

echo $HERE >/tmp/iron.log
echo $LD_LIBRARY_PATH >>/tmp/iron.log

When it starts, by right clicking LAUNCH and Run in Terminal,
LD_LIBRARY_PATH is /opt/Iron-portable/iron64:/opt/Iron-portable/iron64/lib

So I tried, in /opt/Iron-portable/iron64/iron-pup:
export LD_LIBRARY_PATH=/opt/Iron-portable/iron64:/opt/Iron-portable/iron64/lib
and I tried
export LD_LIBRARY_PATH=/opt/Iron-portable/iron64/lib
which I suspected might work.
But curiously, no, it does not work.

I suspect the actual Chrome software is doing something different because of something in the environment.
It doesn't seem to be LD_LIBRARY_PATH.

Maybe it is behaving differently in an interactive shell.

[mikewalsh]

@mikeslr / @williams2 :-

Hallo, Mike/williams2.

I'm well aware of the issue, and it is 'fixable'. I should have posted about it before now. My bad! You were both getting close, just using different approaches.

(Mike; your starting via the right-click 'Run in terminal' effectively by-passed the 'lib' directory. Exactly what works, in this case, for Fossa. Let me explain....)

---

It centres around the self-contained 'lib' directory the 64-bit portables all use. This was part of what battleshooter helped me sort out a few years back when we first started getting all the problems with Chrome. It worked then, and up until now, it's continued to work.....and for every other 64-bit 'clone', too.

(Highly-intelligent lass....and very helpful. We haven't seen her for quite a while because she's currently doing a post-grad course at Uni, as a 'mature student'.)

Davids45 first noticed this a while back, trying to run Chrome-portable under peebee's SCPup64. His terminal output told him there was a conflict with libpangoft2.....Chrome apparently wanting a newer version than the one in the self-contained directory.

Y'see, although the 'lib' directory contains all the 'specific' dependencies that the clones want, it doesn't contain absolutely everything; certain of the 'general' dependencies are provided by Puppy itself, then the 'specifics' are picked up from the built-in directory. With the very newest Puppies, the base system dependencies now require newer versions of the 'specifics' than the built-in directory can provide.

With me so far?

Okay. Now; the answer seems obvious, doesn't it? Re-build the 'lib' directory with all newer versions....yes? Unfortunately, that gets a big fat NO. Things are never that simple.....

IF you 'upgrade' the 'lib' directory, Google_chrome-portable promptly quits working in older Pups. I've tried it; re-built the 'lib' directory with appropriate stuff from both Fossapup itself AND current Quantum (for the NSS libraries, amongst others). By doing that, Fossapup is then the only Pup the portable will function in.

(I'm well aware that at this point, several Puppians will chime in with, "So; where's the problem? You should always run the newest Puppy..." Don't get me started; NOT going there. It's a circular argument...)

---

Under Fossapup64, if you

• Remove the 'lib' directory, and

• Edit the wrapper script to remove the 'LD_LIBRARY_PATH' line

....Fossapup will find everything it needs to run Chrome. It already has the newer string of dependencies that IT requires for the portable to work.

However, the 'lib' directory and 'LD_LIBRARY_PATH' line are still needed for all other Pups. (It's Fossa's requirement for a newer libpango-ft2 that throws a spanner in the works. Everything snowballs from there.)

So; the simplest answer - for now - is to have two 'launchers', and two wrapper scripts. One pair that tell Chrome to use that 'lib' directory.....and the other pair that tell it NOT to use it. It's a lot simpler to point things via scripts that it is to get into an endless 'lib chase'. No way am I producing multiple versions of the same thing just to satisfy different Pups' dependency requirements.

---

At some point in the not too-distant future I'll probably have to work out a more permanent solution, in order for Chrome-portable to remain viable across the Puppy generations. But for now, use the two attached scripts. Place "LAUNCH_nolibs" alongside "LAUNCH", and place "chrome-pup_nolibs" alongside "chrome-pup" INSIDE the 'chrome' directory. For Fossa, launch via the "no_libs" variant. Use the standard launcher for other Puppies. This way, you can continue to share the same 'portable' between multiple Pups.

The same modification will work for the other 'portable-clones'. I shall build them like this for the forseeable future. It's not 'pretty'; it's one of my usual 'bodge-jobs'. But hey! it works.....and adds next to no extra 'weight' to what are already becoming very 'heavy' browsers.

Mike.

[williams2]

not sure what you have done, but I've found in fossapup,
LD_LIBRARY_PATH needs to be unset

like this:
unset LD_LIBRARY_PATH ; /opt/Iron-portable/LAUNCH

or by editing the script.

[mikewalsh]

not sure what you have done, but I've found in fossapup,
LD_LIBRARY_PATH needs to be unset

like this:
unset LD_LIBRARY_PATH ; /opt/Iron-portable/LAUNCH

or by editing the script.

That's it exactly. That's all I've done with the second 'launcher' wrapper-script.....removed the 'LD_LIBRARY_PATH' stanza. But I've added the extra pair of scripts for those who run multiple Puppies, and like to run ONE single 'portable' across multiple Puppies......this way you get to keep the exact same profile all the time, everything always set-up exactly as you want it. Just start it via the 'appropriate' launcher.

(I appreciate that Puppians who only run a single Puppy often have a job understanding why I go to all this trouble..!)

Mike.

[mikeslr]

Hi Mike,

Great, will try that. Having different launcher scripts is nothing to be upset about. After all, they are for different operating systems. By now --with 5000+ puppies-- we should be used to the fact that 'one size doesn't fit all'.

Just to complete the report on my exploration, after posting my comment about installing lxterminal* figured it was worth checking whether anything I installed made a difference. So booted "pfix=ram" and tried portable-iron. It didn't make any difference. So, I'm glad you figured it out.

• why after choosing lxterminal as the default it isn't from "run in terminal" is not the problem of this thread.

[williams2]

ok, I had a few minutes to look at this again.

I edited /opt/Iron-portable/iron64/iron-pup, I added this line:
unset LD_LIBRARY_PATH
just before the exec ... line

It seems to work in Fossapup and also Bionicpup

Same script seems to work in both Pups

It might be the PRELOAD library line in Fossapup that is the difference.

[williams2]

unset LD_LIBRARY_PATH
will conflict with /usr/lib/apulse

FossaPup seems to need to be unset
LD_LIBRARY_PATH= doesn't work
LD_LIBRARY_PATH='' doesn't
Setting LD_LIBRARY_PATH to anything doesn't work.

apulse could be copied or linked to /opt/Iron-portable/iron64/lib
If you can't add apulse to LD_LIBRARY_PATH it might be the only way to get sound in FossaPup.

[williams2]

I installed lxterminal and set it as default almost immediately after deploying fossapup. But the terminal which opened in every instance above was the built-in urxvt

That would be the file /usr/local/apps/Run_In_Terminal/AppRun
specifically the line:

exec urxvt ...

You can change urxvt to lxteminal
Or you can change urxvt to defaultterminal

The options after exec urxvt are urxvt options, they may or may not work properly with other terminal programs.

[williams2]

I edited /opt/Iron-portable/iron64/iron-pup, adding this line:
LD_LIBRARY_PATH=/usr/lib/apulse:
above the exec ... line
LD_LIBRARY_PATH=/usr/lib/apulse: has a colon at the end of the line

It seems to work in FossaPup

[mikeslr]

Thanks again, williams2, this time for the instructions regarding /usr/local/apps/Run_In_Terminal/AppRun.

Mike, I renamed the files and copied them into the appropriate locations in Google_Chrome-protable. Made them executable. Thereafter Google_Chrome-portable started right up. Thanks, again.

Will explore other portables and william2's post just above this tomorrow.

[williams2]

This time i set
LD_LIBRARY_PATH=/usr/lib/apulse
without a trailing colon.
Seems to work, sound works in a youtube kitten video
https://www.youtube.com/watch?v=_uN2aPIdVYI

[williams2]

In FossaPup, sound seems to work with
unset LD_LIBRARY_PATH

I'm not sure what works and what does not work.

[mikeslr]

Following williams2's suggestion:

After a break during which williams2's post was left being displayed, but before stopping all exploration of Puppies for the night, I decided I had time to test his suggestion. Thanks to whoever added the "Duplicate" command to rox's repertoire. Creating iron-pup2 took less than a minute, and creating LAUNCH2 and editing it to call iron-pup2 just a couple second more. Clicking either started portable-iron, although either with the first or the 2nd I received a notice something to the effect of 'profile in use-- do I want to unlock and continue'.

Why it worked raises questions I'll explore tomorrow.

[williams2]

For me, putting the
unset LD_LIBRARY_PATH
line in /opt/Iron-portable/iron64/iron-pup
works, and with sound in youtube videos,

Same script works in both FossaPup and in BionicPup64.

[mikewalsh]

@mikeslr :-

I knew it should work like that, since I've been playing around with multiple launchers/profiles for a couple of years now.....ever since we started using Fred's model of 'portable' browser.

Glad you're sorted.

@williams2 :-

Whilst I agree that using "unset" is probably the more satisfying, technically-correct, properly "geeky Linux" way of doing things in this context, at the end of the day, most users just want things to work.....and many don't really care how, so long as they do.

Like I said, I've always been something of a "bodger"..!

Mike.

[williams2]

Tested the script with unset in XenialPup64, Iron works and sound works.

I tried deleting all the libpulse files in /usr/lib/apulse/
IronPortable still works and sound works.
Iron must be using alsa.
There are no files in the Iron dir named pulse

Firefox does not have sound with the libpulse files deleted.

unset LD_LIBRARY_PATH probably prevents Iron from using libffi.so
libffi.so seems to help javascript use C compiled libraries.
Maybe javascript can run faster if libffi.so is available?
Or maybe not.

[mikewalsh]

@williams2 :-

With regard to the ALSA/PulseAudio question, it seems that the Chromium-based browsers (Chrome itself included, of course), have supported PulseAudio since 2011. In the absence of PulseAudio being found on a user's system, they default to communicating directly with ALSA.

IF, however, PulseAudio is found, the browser will dynamically link a 'built-in' backend to it at runtime. This behaviour is hard-coded at build-time, and is compiled directly into the main 'binary'. I use that term loosely, since the bulk of any Chromium 'clone' is the same as the bulk of a 'zilla-based browser.....it's actually a gigantic 'shared library', but 'binary' is a concept more people can get their heads round..!

Mike.