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: 242
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: 242
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: 3722
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: 3722
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: 242
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: 3722
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: 242
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: 3722
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: 5
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.


Return to “Pale Moon for Linux”

Who is online

Users browsing this forum: gv1234 and 3 guests