'True' Chrome / Chromium portable is a no-no.....

[Mike Walsh]

Afternoon, all.

Well, I know now I'm wasting my time trying to create a 'true' portable package of any Chromium 'clone'.

I've done several portable Mozilla builds, taking my cue from Fred. Not only will these allow keeping absolutely everything inside a single directory, we've discovered that they'll also support running dependencies, and even the glibc itself, from within that same directory.

I've been poking around in the murky depths of the Chromium Project this afternoon. The site's an absolute sodding nightmare to navigate around, but essentially I've learnt that the Linux version of the browser is hard-coded, at build-time, to always look for core dependencies & stuff in system paths only, and to ignore any attempts at re-directs.

Explains why my attempts over this last year or so at creating a 'portable' version of my favourite Iron browser have met with abject failure!

I know Shinobar, HoerMirAuf, and others, have created what they've called 'portable' versions of Chrome.....but in Puppy parlance, what that refers to is anything outside of the save-file/folder. The browser still creates a config directory in /root, and looks for core deps, etc, in /lib and /usr/lib.

Windows builds, naturally, are coded to be far more flexible at build-time, hence why Chromium-portable from PortableApps.com is a reality.....and the dream of something similar for Linux remains just that; a 'dream'.

Never mind. I know now I'm attempting the impossible.


Mike.

[Moose On The Loose]

Afternoon, all.

Well, I know now I'm wasting my time trying to create a 'true' portable package of any Chromium 'clone'.

How about a partial solution:
Put all the stuff on the hard drive.
Put links in the places Chrome looks.
If that works, maybe you can make a script that does all the links.

[Mike Walsh]

@ Moose On The Loose:-

Hah! I know where you're coming from, Moose, and I appreciate the sentiment. The fact of the matter is that for something like the last 3 years I've done exactly that; shared a single version of a Chromium 'clone' between multiple Puppies, from a remote data partition, and sym-linked into each one where Pup expects to see it. I have a 'sym-link' .pet made up (nothing but symlinks!), and any time I add, or try out, a new Puppy, I just use the .pet to 'link' Pup to that remote browser install.

It works very well.

No; what I was attempting to do was to make up a truly 'portable' Chromium clone, self-contained in its own directory (just like the portable version that PortableApps.com have put together for Windoze), which, if you wanted to, could be run from a flash drive.....thus making it truly 'portable'.

Of course, I could be using completely the wrong Bash syntax. Despite the fact that I've set this portable up to use its own, built-in version of Glibc 2.19, along with certain other 'requirements', it's still resolutely searching in the file system to find them, and completely ignoring the resources already provided. Or is

Code: Select all

export LC_ALL=C

....not the 'phrasing' to use on this occasion? Any ideas?


Mike.

[williams2]

LC_ALL is a locale setting.
For example, fr (French), ru (Russian), uk (United Kingdom) etc.
C is a very basic generic locale, like LC_ALL=us

You can set PATH and LD_LIBRARY_PATH and Chromium
or whatever you are running should use those variables.

For example, this should make Chromium look first in /opt/chromium
for executables and library files, then the standard paths:

Code: Select all

export PATH=/opt/chromium:$PATH
export LD_LIBRARY_PATH=/opt/chromium:$LD_LIBRARY_PATH

If the Chromium files are not in /opt/chromium it won't work.

If you click the start script in a roxfiler window
or an icon on the desktop
rox always includes the dir path.
So this will tell you the path of the script you clicked:

Code: Select all

dirname "$0"

So you could do something like this:

Code: Select all

#!/bin/sh
DIR="$(dirname "$0")"
export PATH=$DIR:$PATH
export LD_LIBRARY_PATH=$DIR:$LD_LIBRARY_PATH
exec chromium "$@"

You might need more quotation marks if there are spaces in the path names.

[Mike Walsh]

@ williams2:-

Right.....

Okay. Try this on for size......& get your considering cap on, 'cos it might get a bit 'tricky'.

---------------------------------------------------------------------

For me, /mnt/sda1 is a large, general data partition. It got re-purposed when Win XP bit the dust 3-4 yrs ago. Now; I run a lot of stuff, remotely, from this partition between Pups....okay?

The app (Iron browser) that I'm attempting to run is located at /mnt/sda1/iron-portable/iron32/iron. However, this 'iron' directory gets sym-linked into /mnt/home of the Puppy I wish to run it from, so effectively it's /mnt/home/iron.....which puts it outside of Puppy-space.

------------------------------------------------------------------------

This directory, in addition to the Iron browser components, also contains the following:-

- A self-contained 'copy' of Tahrpup's Glibc 2.19 and all its associated dependencies, etc. This is how we get external browsers to run on older Pups, with too-old glibc components.

- A 'lib' directory, containing the GTK3, pulse & NSS components required by Iron.

- A 'hidden' .config directory, where Iron will write its profile to when it starts up for the first time (/mnt/home/iron/.config/iron).

- A script, called 'launch', which sets the browser to use the built-in glibc components. This then passes control to the

- 'iron-pup' wrapper script, which starts Iron proper, looking for the GTK3 and NSS stuff in /mnt/home/lib as it does so.

----------------------------------

The 'launch' script looks like this:-

Code: Select all

#!/bin/sh
#
export LC_ALL=C
/mnt/home/iron/glibc219/lib/ld-linux.so.2 --library-path /mnt/home/iron/glibc219/lib:/mnt/home/iron/glibc219/usr/lib:/mnt/home/iron/glibc219/libstdc++:/usr/X11R7/lib:/mnt/home/iron /mnt/home/iron/iron-pup "$@"

Some of the older Pups still use X11R7 for X-server stuff.

---------------------------------

'iron-pup' reads as follows:-

Code: Select all

#!/bin/sh
#
# Try to find GTK3/NSS libraries, etc.
#
export LD_LIBRARY_PATH=/mnt/home/iron/lib:$LD_LIBRARY_PATH
#
exec -a "$0" /mnt/home/iron/chrome --user-data-dir=/mnt/home/iron/.config/iron --no-sandbox --disable-infobars --ppapi-flash-path=/mnt/home/iron/lib/mozilla/plugins/libpepflashplayer.so --allow-outdated-plugins "$@"

'Lib' also contains 'libpepflashplayer.so' and its associated 'manifest.json' in a sub-directory. The phrases starting with ('--') are some of the 1001 'switches' with which you can modify many aspects of a Chromium 'clone's' behaviour.

---------------------------------------------

Now; everything here is 'ELF 32', OK? Yet, attempting to start this, and run it, in a 32-bit Puppy, I'm getting a 'Wrong ELF header' error in the terminal. There's no 64-bit stuff anywhere in sight, but AFAIK, that error means you're trying to use/run/operate the app in the wrong architecture. So; what gives?

Any ideas?

(I'm not entirely. certain I'm using these two scripts the right way round. In the Mozilla-based portables with the glibc 'tweak', we run a launch script first that sets system variables, and instructs the browser to create & then use its own, built-in profile directory rather the standard one located in /root. This then passes control across to the other script, that sets the glibc paths and starts the browser directly from the 'firefox' binary.

You can't do this with the Chromium clones, since the entire browser code is contained within a single, enormous shared library; this is why the wrapper script is required, an essential part of which is specifying the '--user-data-dir' (profile directory) at that specific point in the start-up sequence. That's just the way they're coded to work.)


Mike.

[williams2]

You can get a lot of info doing this:

Code: Select all

export LD_DEBUG=libs
run-me 2>/tmp/debug.log

where run-me is the name of the program you are running
and /tmp/debug.log is the debug log.

Maybe too much info.

[williams2]

You can find 64 bit files like this:

Code: Select all

find /mnt/home/iron/chrome/ | xargs file | grep 64-bit

You can search in more than 1 dir, separated by spaces,
like this:
find /bin/ /sbin/ /lib/ ...

When you mix shared object library files,
there can be compatiblity problems.
If ld-linux.so and/or libc.so are linking with software
that was compiled for other ld-linux.so and/or libc.so,
it might not work.

It might not be possible to make the files
work compatibly.

[fredx181]

Hi Mike,

It could be that the setup with older Glibc doesn't work with iron, but a portable setup is possible from what I tested (just like the portable FF Quantum).
I got iron from here:
https://www.srware.net/forum/viewtopic.php?f=18&t=49378
And changed the last line in the 'chrome-wrapper' script (to have profile and cache inside folder) to this:

Code: Select all

exec $CMD_PREFIX "$HERE/chrome" --no-sandbox --disable-infobars --user-data-dir=$HERE/profile --disk-cache-dir=$HERE/profile/cache --disk-cache-size=10000000 --media-cache-size=10000000 --allow-outdated-plugins "$@"

Fred

[Mike Walsh]

Hi Mike,

It could be that the setup with older Glibc doesn't work with iron, but a portable setup is possible from what I tested (just like the portable FF Quantum).
I got iron from here:
https://www.srware.net/forum/viewtopic.php?f=18&t=49378
And changed the last line in the 'chrome-wrapper' script (to have profile and cache inside folder) to this:

Code: Select all

exec $CMD_PREFIX "$HERE/chrome" --no-sandbox --disable-infobars --user-data-dir=$HERE/profile --disk-cache-dir=$HERE/profile/cache --disk-cache-size=10000000 --media-cache-size=10000000 --allow-outdated-plugins "$@"

Fred

@ Fred:-

The version I'm using (Iron 69) ought to work with the 'glibc219' directory, because it runs in Tahr 606.....and that's where watchdog originally sourced the components from. (I'm not using the very newest version, because NetFlix resolutely insists it can no longer 'see' the WideVine modules in the latest releases..... Go figure.)

I'll give your suggestion a try tomorrow, and see what, if anything, happens.

Cheers!


Mike.

[jrb]

Never mind. I know now I'm attempting the impossible.

Good thing I didn't read your post before I started trying to make Vivaldi-portable. Granted, it still makes an empty folder /root/.config/vivaldi/Crash Reports, but everything else is in /initrd/mnt/dev_save/0_common/0_hardrive_apps/vivaldi226 except the Cache files which are in /tmp/vivaldi.

To get it to run in Precise-light I had to bump up to Glibc-2.26 (used a Slitaz module) and dump a bunch of libs from the Tahr repos into the Vivaldi folder. Took a bit of fiddling but I finally got it going.

I tried to get it to use a Glibc "tweak" but no luck. Finally put the Glibc-2.26 into adrv_precise_light-5.7.2.sfs and that did it.

Maybe Vivaldi is set up differently than the other clones. I'll have a look when I get some time.

Don't give up. Cheers, J