A linux build framework for Pale Moon

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

Moderator: trava90

Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Unread post by Walter Dnes » 2017-03-07, 01:53

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.
There's a right way
There's a wrong way
And then there's my way

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Unread post by Walter Dnes » 2017-03-07, 11:58

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.
There's a right way
There's a wrong way
And then there's my way

JotaMG

Re: A linux build framework for Pale Moon

Unread post by JotaMG » 2017-03-07, 12:32

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.

New Tobin Paradigm

Re: A linux build framework for Pale Moon

Unread post by New Tobin Paradigm » 2017-03-07, 12:56

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.

JotaMG

Re: A linux build framework for Pale Moon

Unread post by JotaMG » 2017-03-07, 13:09

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?

New Tobin Paradigm

Re: A linux build framework for Pale Moon

Unread post by New Tobin Paradigm » 2017-03-07, 13:12

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.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Unread post by Walter Dnes » 2017-03-07, 22:03

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.
There's a right way
There's a wrong way
And then there's my way

New Tobin Paradigm

Re: A linux build framework for Pale Moon

Unread post by New Tobin Paradigm » 2017-03-08, 04:11

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.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Unread post by Walter Dnes » 2017-03-08, 07:04

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.
There's a right way
There's a wrong way
And then there's my way

JotaMG

Re: A linux build framework for Pale Moon

Unread post by JotaMG » 2017-03-08, 13:13

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

New Tobin Paradigm

Re: A linux build framework for Pale Moon

Unread post by New Tobin Paradigm » 2017-03-08, 13:29

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!

Peregrine

Re: A linux build framework for Pale Moon

Unread post by Peregrine » 2017-04-28, 17:43

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
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Unread post by Walter Dnes » 2017-04-28, 20:21

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.
There's a right way
There's a wrong way
And then there's my way

Peregrine

Re: A linux build framework for Pale Moon

Unread post by Peregrine » 2017-04-29, 12:32

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.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Unread post by Walter Dnes » 2017-04-30, 01:13

Peregrine wrote: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).
32-bit posix (unix/linux/bsd) as we know it is going to die in January 2038 https://en.wikipedia.org/wiki/Year_2038_problem unless 64-bit time_t is backported to 32-bit OS's. This might be possible, but would be quite painfull. Arm 64-bit cpu's are growing in popularity and will take over by 2038, so no problem.
Peregrine wrote: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.
Note about resolutions
  1. 1080p = 1920 x 1080
  2. 720p = 1280 x 720
"Decent drivers" are that way because they use advanced instructions. Some years ago, Flash went to requiring SSE2 code for linux, and older machines couldn't run newer Flash. I've got a 1920x1080p monitor hooked up to an Dell Intel desktop with a standard on-board chip. The roller-coaster video https://www.youtube.com/watch?v=9dC6uJDNf64 plays smoothly and stutter-free in HTML5 in full screen mode with the 1080p version selected. I also have an ancient Lenovo T400 Thinkpad with a CORE2 cpu and a standard onboard video chip. The screen is 1280x800, so I selected 720p, i.e. 1280x720 Youtube mode. "Fullscreen" mode results in a thin black strip along the top and bottom. 720p runs fine on the Thinkpad.

See my post of April 10 in thread viewtopic.php?f=37&t=13872&p=111593 for hints about squeezing the last bit of performance out of your video. With the wrong video card/driver, you may experience problems... you have been warned.
Peregrine wrote: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.
I repeat... only a very small percentage of linux machines run musl. A musl-compiled Pale Moon would only run on a musl-based linux machine. It's pointless.
Peregrine wrote: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.
In Gentoo, the output from "emerge -pv palemoon" should list all USE flags. In general, "emerge -pv <program>" will list all USE flags for "program". The "octopus" overlay Pale Moon ebuild seems to be favoured on the Gentoo mailing list. The only problem is that it has to be editied to not halt if you have GCC 5. Gentoo recently switched over to GCC-5.4.0, and preliminary reports are that Pale Moon builds and runs fine with GCC-5.4.0 on Gentoo.
There's a right way
There's a wrong way
And then there's my way

Peregrine

Re: A linux build framework for Pale Moon

Unread post by Peregrine » 2017-04-30, 18:00

Walter Dnes wrote: I repeat... only a very small percentage of linux machines run musl. A musl-compiled Pale Moon would only run on a musl-based linux machine. It's pointless.
Can't (any) linux have both glibc and musl libraries installed ? And use any one of these depending on the program in question. Pale Moon could then use musl on distro's that have and use glibc standardly for its other programs.
Walter Dnes wrote: The "octopus" overlay Pale Moon ebuild seems to be favoured on the Gentoo mailing list.
Yup. Found it: https://github.com/Bfgeshka/octopus/blo ... 3.0.ebuild

As for the rest:
Walter Dnes wrote: 32-bit posix (unix/linux/bsd) as we know it is going to die in January 2038 https://en.wikipedia.org/wiki/Year_2038_problem unless 64-bit time_t is backported to 32-bit OS's. This might be possible, but would be quite painfull. Arm 64-bit cpu's are growing in popularity and will take over by 2038, so no problem.
I guess I'll just keep using my 32-bit PC untill it stops working, and then switch to whatever is still available 2nd hand and is also cheapest.
Walter Dnes wrote: Note about resolutions
  1. 1080p = 1920 x 1080
  2. 720p = 1280 x 720
I've got a 1920x1080p monitor hooked up to an Dell Intel desktop with a standard on-board chip. The roller-coaster video https://www.youtube.com/watch?v=9dC6uJDNf64 plays smoothly and stutter-free in HTML5 in full screen mode with the 1080p version selected. I also have an ancient Lenovo T400 Thinkpad with a CORE2 cpu and a standard onboard video chip. The screen is 1280x800, so I selected 720p, i.e. 1280x720 Youtube mode. "Fullscreen" mode results in a thin black strip along the top and bottom. 720p runs fine on the Thinkpad.
Yes, as I said: never used 1080p, not even 720p. I just use plain 1024x768 as general resolution, and always use the 480p resolution in youtube (854x480px). It might be able to run at higher resolution, but often that affects speed, so I keep it at 480p. That's good enough.
Walter Dnes wrote: See my post of April 10 in thread viewtopic.php?f=37&t=13872&p=111593 for hints about squeezing the last bit of performance out of your video. With the wrong video card/driver, you may experience problems... you have been warned.
I just use the vesa drivers. Less configuration hassle.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: A linux build framework for Pale Moon

Unread post by Walter Dnes » 2017-04-30, 21:50

Peregrine wrote:Can't (any) linux have both glibc and musl libraries installed ? And use any one of these depending on the program in question. Pale Moon could then use musl on distro's that have and use glibc standardly for its other programs.
No. A lot of linux APIs call other APIs in specific files. glibc and musl (and uclibc-ng) provide the same expected APIs in the same file name. They would overwrite each other's files when installing.
There's a right way
There's a wrong way
And then there's my way

Locked