A linux build framework for Pale Moon

Support and discussions for the x86/x64 Linux version of Pale Moon.

Moderators: trava90, satrow, Indalecio

Walter Dnes
Fanatic
Fanatic
Posts: 244
Joined: Thu Jul 30, 2015 8:29 pm
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Postby Walter Dnes » Tue Mar 07, 2017 1:53 am

Yeah, but... I'd really like to have a full-fledged browser on uclibc.. And, no, Dillo 3.x does not cut it. I've got Pale Moon to build under uclibc-ng, but it crashes soon after launching, with weird error messages.

Walter Dnes
Fanatic
Fanatic
Posts: 244
Joined: Thu Jul 30, 2015 8:29 pm
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Postby Walter Dnes » Tue Mar 07, 2017 11:58 am

Matt A Tobin wrote:You guys do realize you are going WAY the hell out of spec for Pale Moon builds right?

I may have to give up on it. Actually managed to build and launch it under uclibc-ng, but it freezes soon after...

Code: Select all

LD_LIBRARY_PATH=/home/waltdnes/pm/palemoon /home/waltdnes/pm/palemoon/palemoon

GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not
be saved or shared with other applications.
/home/waltdnes/pm/palemoon/palemoon: '/usr/lib/libc.so' is not an ELF file
/home/waltdnes/pm/palemoon/palemoon: '/usr/lib/libc.so' is not an ELF file
*************************
A coding exception was thrown and uncaught in a Task.

Full message: TypeError: Stat.xstat is not a function
Full stack: stat@resource://gre/modules/osfile/osfile_unix_back.jsm:630:19
stat@resource://gre/modules/osfile/osfile_unix_front.jsm:934:36
stat@resource://gre/modules/osfile/osfile_async_worker.js:187:1
worker.dispatch@resource://gre/modules/osfile/osfile_async_worker.js:31:26
anonymous/AbstractWorker.prototype.handleMessage@resource://gre/modules/workers/
PromiseWorker.js:122:16
@resource://gre/modules/osfile/osfile_async_worker.js:46:43

*************************


The bit between the asterisks repeats several times, and Pale Moon eventually freezes.

JotaMG
Hobby Astronomer
Hobby Astronomer
Posts: 16
Joined: Thu Feb 23, 2017 7:49 pm

Re: A linux build framework for Pale Moon

Postby JotaMG » Tue Mar 07, 2017 12:32 pm

Matt A Tobin wrote:You guys do realize you are going WAY the hell out of spec for Pale Moon builds right?


Well, I'm new to Palemoon, I don't know who you are, but I can tell that, apart from stevepusser and Walter, the PM community has been a disappointment, and not very helpful.
In particular, I was expecting that some of the core devs to step in and offer some guidance.
Instead I got negative comments.
Strange.
J.

User avatar
Matt A Tobin
Knows the dark side
Knows the dark side
Posts: 3726
Joined: Tue Oct 09, 2012 7:37 pm

Re: A linux build framework for Pale Moon

Postby Matt A Tobin » Tue Mar 07, 2017 12:56 pm

Let me clear something up.. I haven't been a direct member of this project for almost 5 months.

I am sorry you feel that way but I feel nothing in this thread has any material benefit to the over all project. While I support stevepusser for managing debian-style packages and his commitment to glorious science and learning.. Whatever the hell Walter Dnes is doing or trying to accomplish while presenting a perception of practical gains and over all experience and authority ends up being a bunch of non-supported, not recommended, and frankly insane ramblings continuing on for over a year now about configuration and compiler options that should be ripped out for being unsupported, not recommended, and insane.

Also, what is the point of all this "Linux Build Framework" nonsense anyway.. A learning experience for science or something that has any practical use beyond one specific configuration? Someone needs to decide.
Image

JotaMG
Hobby Astronomer
Hobby Astronomer
Posts: 16
Joined: Thu Feb 23, 2017 7:49 pm

Re: A linux build framework for Pale Moon

Postby JotaMG » Tue Mar 07, 2017 1:09 pm

Well, Palemoon could have been the default browser in a upcoming x32 ABI distro, that will be evaluated on major tech sites.
If this is not good publicity for Palemoon and a benefit for the project, then what it is?

User avatar
Matt A Tobin
Knows the dark side
Knows the dark side
Posts: 3726
Joined: Tue Oct 09, 2012 7:37 pm

Re: A linux build framework for Pale Moon

Postby Matt A Tobin » Tue Mar 07, 2017 1:12 pm

Which distro.. What is it based on.. Why is it only 32bit. How is this theoretical Build Framework gonna help.. How is going outside of spec for build configuration going to be acceptable? What is wrong with standard build procedure and steps?

Everything seems very vague...

Also, I must remind everyone using system libs instead of the ones in the tree is not only not recommended but is not supported.

Additionally, the product's name is Pale Moon not Palemoon, palemoon, PaleMoon, PaLeMoOn.. Two words, both capitalized.
Image

Walter Dnes
Fanatic
Fanatic
Posts: 244
Joined: Thu Jul 30, 2015 8:29 pm
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Postby Walter Dnes » Tue Mar 07, 2017 10:03 pm

Matt A Tobin wrote:Also, what is the point of all this "Linux Build Framework" nonsense anyway.. A learning experience for science or something that has any practical use beyond one specific configuration? Someone needs to decide.

It's a recognition of the fact that "one-size-does-not-fit-all". If you want to tick off every checkbox in a feature list, you end up with a bloated monstrosity like MS Office. Not everybody has the latest/greatest dev machine with 16 gigs of ram. For a lot of people who aren't at least middle-class, an older machine with a lightweight distro is the only choice, e.g. " Lucid Puppy Revitalized as 5.2.8.7 - December, 2016" http://www.murga-linux.com/puppy/viewtopic.php?t=90461 Although it uses older glibc, etc, it does have security fixes (Ghost, etc) backported.

In my case, I do have 2 functioning 8-gig desktop machines, but I also have an ancient Atom netbook with 2 gigs of ram and an off-lease Lenovo T400 with 4 gigs of ram. They're cheap enough that I'm not afraid to lug them around with me, and they're still decent machines for staying in touch when travelling. Let's just say that every bit of optimization, and code trimming helps.

Yes, there have been a couple of attempts to build for unsupported architectures. But it's not the developers wasting their time. I recognize that the main project can't possibly satisfy everybody's specific needs/desires. If someone is motivated enough to roll-their-own, it shouldn't be a problem for the developers.

User avatar
Matt A Tobin
Knows the dark side
Knows the dark side
Posts: 3726
Joined: Tue Oct 09, 2012 7:37 pm

Re: A linux build framework for Pale Moon

Postby Matt A Tobin » Wed Mar 08, 2017 4:11 am

And I'm telling you that is not how this codebase works and if your roll-your-own incarnation is intended for redist you must follow our feature set and some standards on building otherwise what you end up with won't be Pale Moon or have commonality with the regular linux builds and won't be allowed to carry the branding.. Your low resource distro and stripped down build with missing features and corrupt build setup setup is not within spec and helps no one..

Why not help with something that matters like better support on newer gcc versions. Something like that could help us all. Otherwise if you want to make a new custom low resourae browser merely BASED on Pale Moon then have at it.. I've made rebranding easier than ever.
Image

Walter Dnes
Fanatic
Fanatic
Posts: 244
Joined: Thu Jul 30, 2015 8:29 pm
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Postby Walter Dnes » Wed Mar 08, 2017 7:04 am

Matt A Tobin wrote:And I'm telling you that is not how this codebase works and if your roll-your-own incarnation is intended for redist you must follow our feature set and some standards on building otherwise what you end up with won't be Pale Moon or have commonality with the regular linux builds and won't be allowed to carry the branding.. Your low resource distro and stripped down build with missing features and corrupt build setup setup is not within spec and helps no one..

I'm not doing a redistribution. My intention is to be able to do one-off builds for my machines at home. I assume other people may want to do something similar, which is why I'm sharing my code. Note that my current SSE-for-linux contributed build follows the mainline build except for...
1) specifying "-mmmx -msse -mno-sse2" instead of "-msse2 -mfpmath=sse"
2) devtools are disabled
3) --enable-stdcxx-compat to support older libs
4) No Gstreamer support, period, rather than disabling by default. (long story)

Matt A Tobin wrote:Why not help with something that matters like better support on newer gcc versions. Something like that could help us all.

I am not a programmer per se. I'm retired, and in my mid 60's. The first languages I learned were FORTRAN and BASIC. I can do amazing tricks with bash scripts, but that's the extent of my programming ability. I took a C programming course once, but I've probably forgotten most everything. Having said that, I can follow instructions and run gcc.

I understand, that at one point, the devs were looking at gcc 5.x for the linux build, but backed off because of problems. Steve Pusser had problems recently when Debian/Ubuntu went to gcc 5.x, and he had to back off to 4.9.x

My personal desktop build at home with gcc 5.4.0 #WORKSFORME on my Gentoo machine, which is otherwise running on gcc 4.9.4. Maybe I'm lucky. Or maybe it's because I manually built gcc 5.4.0 specifying the "--with-default-libstdcxx-abi=gcc4-compatible" option. I have mentioned this to Travis in the past. But he told me to stick with 4.9.x, to keep the SSE-only build in sync with the mainline build. I had assumed that gcc 5.x is simply one more "unsupported environment". I can do gcc 5.4.0 32-bit builds on request. I assume that the devs would have to ask for volunteer beta testers.

JotaMG
Hobby Astronomer
Hobby Astronomer
Posts: 16
Joined: Thu Feb 23, 2017 7:49 pm

Re: A linux build framework for Pale Moon

Postby JotaMG » Wed Mar 08, 2017 1:13 pm

Matt A Tobin wrote: Additionally, the product's name is Pale Moon not Palemoon, palemoon, PaleMoon, PaLeMoOn.. Two words, both capitalized.


Also, two words:
F |_| C K
Y O U

G'Bye,
Jorge

User avatar
Matt A Tobin
Knows the dark side
Knows the dark side
Posts: 3726
Joined: Tue Oct 09, 2012 7:37 pm

Re: A linux build framework for Pale Moon

Postby Matt A Tobin » Wed Mar 08, 2017 1:29 pm

Walter Dnes, I supposed the main thing I have a problem besides potentially putting ideas into peoples heads to use not recommended, poorly understood, and potentially damaging build config is that you are using the forum as your own personal blog.. For which it is not.

JotaMG, Fragile sensibilities from a special snowflake crybaby.. Never seen that before. Oh well. Peace!
Image

Peregrine
Newbie
Newbie
Posts: 6
Joined: Mon Oct 26, 2015 8:39 am
Location: planet earth, orion arm, milky way, the universe

Re: A linux build framework for Pale Moon

Postby Peregrine » Fri Apr 28, 2017 5:43 pm

Hi,
I've been looking over the messages in this post and wanted to propose an alternative idea, that's "more or less" in line with the initial ideas proposed by Walter Dnes.

From what I gather, the initial idea for the framework was to drop dbus (which I actually also thought about, and consider a good thing). However, as Tobin pointed out, at this particular moment, the changes thus needed to pale moon would be rather extreme, so perhaps for the time being it isn't a good time to do this.

Also of intrest to Walter is specific support for certain processors (like SSE). I think this is something that should be dropped. Why don't we just focus on making it as generic as possible ? So support only plain x86 and perhaps x86_64, don't make it amd or pentium specific, nor any subspecies of these cpu's. There simply aren't enough developers to do such things (as it requires a lot of work, and only provides merit to a small part of the community). Also, I think that swapping the libc (see below) is going to give a greater speed increase than simply compiling it specifically for your processor, so I'd focus on getting this implemented first.

Another thing Walter's working on is to use uclibc (or well uclibc-ng) instead of glibc (see viewtopic.php?t=11951). This is a lot better than glibc, and definitely preferable.
However, what has also been proposed (over at github this time, see https://github.com/MoonchildProductions ... issues/366 ) is to use musl instead.
Musl seems to be replacing both glibc and uclibc nowadays, is even a bit faster than uclibc, and even more importantly, a lot safer than both of these. Pale Moon focuses on not only speed but also security, so I don't see why we're not swapping to this by default. You can read http://www.etalabs.net/compare_libcs.html for an comparison of these 3 libc's.

Walter Dnes
Fanatic
Fanatic
Posts: 244
Joined: Thu Jul 30, 2015 8:29 pm
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Postby Walter Dnes » Fri Apr 28, 2017 8:21 pm

Peregrine wrote:From what I gather, the initial idea for the framework was to drop dbus (which I actually also thought about, and consider a good thing). However, as Tobin pointed out, at this particular moment, the changes thus needed to pale moon would be rather extreme, so perhaps for the time being it isn't a good time to do this.

This is a personal preference. I was wiling to live with the "lost features" on my machine. That's one of the nice things about roll-your-own; I can optimize it for my wants/needs and my hardware.

Peregrine wrote:Also of intrest to Walter is specific support for certain processors (like SSE). I think this is something that should be dropped. Why don't we just focus on making it as generic as possible ? So support only plain x86 and perhaps x86_64, don't make it amd or pentium specific, nor any subspecies of these cpu's. There simply aren't enough developers to do such things (as it requires a lot of work, and only provides merit to a small part of the community).

A few comments on that.
  1. It's not extra coding work on the developers' part. It's a matter of running the same code through the build process, with a tweaked mozconfig. I've already gone to the effort of setting up a 32-bit chroot on my 64-bit host. Inside the chroot, I set up the build framework to do custom builds for my Atom netbook, and for a Lenovo T400. It was a minor incremental effort for me to add 1 more build directory for the SSE version, symlink to the source code directory, and tweak the mozconfig file to official Pale Moon specs. Build time is just under 25 minutes.
  2. There are actually quite a few people with older Pentium 3-class machines (SSE-only). Puppy Linux uses older, smaller libs, with security fixes backported. See http://www.murga-linux.com/puppy/index.php
  3. The problem with "as generic as possible" is that it means "lowest common denominator". The source code, inherited from Firefox, comes with options to use variants of SSE2, SSE3, and SSE4, if specified. These instructions are useful in speeding up video rendering. Indeed, they're necessary if you want to do smooth 1080p playback in HTML5. This is another nice part of doing a custom build for my machine with "-march=native". Optimizing in Gentoo does not mean being a "Gentoo ricer" ;) . For the mainstream build, it comes down to a balance between working on as many machines as possible, versus getting decent performance
  4. There are seperate considerations for 32-bit and 64-bit architectures. I'm using https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options as a reference
  5. Pentium3 class machines (i.e. MMX and SSE on top of basic i686) can only do 32-bit mode, so there is no point in a 64-bit SSE version
  6. All Intel cpus that can handle 64-bit mode have a minimum of MMX, SSE, SSE2, and SSE3 support. AMD went 64-bit earlier. The earliest 64-bit AMDs support MMX, SSE, SSE2, 3DNOW!, and enhanced 3DNOW! instructions. That's probably why the cutoff at SSE2 support. Going to SSE3 would drop support for some earlier AMD Athlons.

Peregrine wrote: Also, I think that swapping the libc (see below) is going to give a greater speed increase than simply compiling it specifically for your processor, so I'd focus on getting this implemented first.

Another thing Walter's working on is to use uclibc (or well uclibc-ng) instead of glibc (see viewtopic.php?t=11951). This is a lot better than glibc, and definitely preferable.
However, what has also been proposed (over at github this time, see https://github.com/MoonchildProductions ... issues/366 ) is to use musl instead.

The problem with that is that <whatever>-libc in Pale Moon has to run on a user machine with the same <whatever>-libc. And right now, the overwhelming vast majority of linux machines are built on glibc. I was trying an experiment on my own personal machine. For the record, even with some ugly hacks, I could not get Pale Moon built under uclibc-ng.

If we're going off the beaten path, at least stick with something that doesn't require a major rebuild on end-users' machines. IANAP (I Am Not A Programmer). If I were, I'd be working on migrating Pale Moon away from GTK to FLTK (Fast Light Tool Kit) http://www.fltk.org/index.php. GTK2 is reaching end-of-life, and I really dread the thought of building Pale Moon on GTK3. GTK is allegedly not supposed to stand for "GNOME Tool Kit", but it seems to. The paranoid side of me wouldn't be surprised if GTK4 had hard-coded dependancies on systemd and Pulse Audio.

Peregrine
Newbie
Newbie
Posts: 6
Joined: Mon Oct 26, 2015 8:39 am
Location: planet earth, orion arm, milky way, the universe

Re: A linux build framework for Pale Moon

Postby Peregrine » Sat Apr 29, 2017 12:32 pm

Peregrine wrote:Also of intrest to Walter is specific support for certain processors (like SSE). I think this is something that should be dropped. Why don't we just focus on making it as generic as possible ? So support only plain x86 and perhaps x86_64, don't make it amd or pentium specific, nor any subspecies of these cpu's. There simply aren't enough developers to do such things (as it requires a lot of work, and only provides merit to a small part of the community).

After rereading this, I guess I was a bit too strict here. It certainly does have a merit and can speed up things quite a bit for SSE cpu users. So not doing further builds of this is overkill. Still, I still use even older hardware and some of use probably do as well. Also, special cpu's (which are still used today) -like ARM- can't use it, and I also doubt those smartphone-derived CPU's can use it (for example the CPU in the raspberry Pi 2, and similar single-board pc's). They're also still 32-bit btw. These are sold a lot these days, and I think they'll only get more popular. Most people don't need a super-fast PC, and like to just buy cheap machines, and also have it consume less electricity (=even cheaper in use and more ecological).

Btw: you mention SSE2 and older versions can help with high-end purposes like "1080p playback in HTML5". I never even played anything in 1080p, in my entire life ;). Also, if I would have a need for something like this, isn't this better solved with a good graphics card (rather than a on-board graphics chip) and making sure we run decent drivers to make effective use of this ? I doubt better support of SSE will make an equally large difference.

Walter Dnes wrote:The problem with that is that <whatever>-libc in Pale Moon has to run on a user machine with the same <whatever>-libc. And right now, the overwhelming vast majority of linux machines are built on glibc. I was trying an experiment on my own personal machine. For the record, even with some ugly hacks, I could not get Pale Moon built under uclibc-ng.

Has anyone ever tried to build it with musl ? If so, did that work or are there issues that still need solving ?

Walter Dnes wrote:IANAP (I Am Not A Programmer). If I were, I'd be working on migrating Pale Moon away from GTK to FLTK (Fast Light Tool Kit) http://www.fltk.org/index.php. GTK2 is reaching end-of-life, and I really dread the thought of building Pale Moon on GTK3.

Same here. I also wouldn't want to use GTK3 or GTK4. FLTK can be an option, but there are others as well, like EDE, GNUStep, WxWidgets, ...
However, that's a problem for later-on. I think having Pale Moon run on musl by default will be the first thing to solve.

I think that supporting musl by default would best be done for all linux versions.
We could start by first trying it with gentoo though. Regarding this, there currently still isn't any official version of Pale Moon at the gentoo repo's (see https://packages.gentoo.org/categories/www-client ). So it can only be build with an overlay at present (like the one at https://github.com/deuiore/palemoon-overlay ).
So one would need to do:
# layman -d palemoon
add "source /var/lib/layman/make.conf" and PORTDIR_OVERLAY="/usr/local/portage/ ${PORTDIR_OVERLAY}" in make.conf
add "conf_type : repos.conf" in layman.conf
# layman -a palemoon
# emerge -a palemoon

However, I don't know yet whether any use flags can be used with layman (I'm pretty new to gentoo too). Also, the absence of a palemoon page at packages.gentoo.org also means I'm not sure what local/global use flags can be specified. Is there a complete list of these for palemoon ? I found some at https://gpo.zugaina.org/www-client/palemoon but I wonder whether those listed ther are only local use flags, and/or whether some can also be used globally. Also, it's not a complete list probably.


Return to “Pale Moon for Linux”

Who is online

Users browsing this forum: No registered users and 6 guests