As mentioned on earlier posts, me and VCTLabs are building the TAZ distro that is also going to include palemoon as the main browser. The entire distro (thus including palemoon) is going to run on musl. There have been a few attemps in the past to make palemoon run on musl, but so far nothing has been successful (to my knowledge). VCTLabs however has gotten us so far that it already runs on musl. However, at the moment there are still a few issues:* jemalloc doesn't work (see https://github.com/jemalloc/jemalloc/issues/1238 ) -issue currently avoided turning jemalloc off-* palemoon crashes on the first run (see images) but gets far enough to create its profile directory. * once the profile is created it does not crash on startup, but font rendering is all messed up (see images)

Note that we intent to work with deu to implement the musl build option (hence allowing to build with either glibc or musl).Deu mentioned that he is probably going to upload the v28 ebuild to gentoo packages, so when that happens (and he implements the musl build option) we'll have the ability to build with musl, for version 28 and probably all later versions too.

Attachments

Last edited by Peregrine on Fri, 08 Jun 2018, 11:21, edited 3 times in total.

I ported the Pale Moon to musl couple months ago. It runs just fine on Alpine Linux with musl-libc (gcc-6.4) except some rare cases. I didn't make it public at first because I was a bit reluctant about it. Since you're also working on it, my work may be helpful to solve your problems.

terranigma wrote:What about other Gtk-2 applications? Are fonts rendering properly?

Yes - geany, claws, and some lxde stuff were all compiled against it, and all those others can render fonts.HOWEVER, those were all compiled with a newer toolchain, whereas we switched to gcc-4.9 when building palemoon per Deu's recommendation. The tanertas build uses the gcc-6.4 toolchain since that is the only available toolchain on Alpine currently. So perhaps running palemoon on gcc-6.4 might help.

"-Os" reduces binary size, but slows down the executable that you build. I recommend "-O2 -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer" instead. "-O2" optimizes for speed. The GCC flags "-fno-asynchronous-unwind-tables -fomit-frame-pointer" get rid of DWARF2 tables, which knocks 15% off the size of the compiled binary. This speeds up loading time (less to load) and uses corespondingly less ram. See 2 posts from the busybox mailing list http://lists.busybox.net/pipermail/busybox/2012-September/078326.html and http://lists.busybox.net/pipermail/busybox/2012-September/078331.html. These guys are busybox developers, not "Gentoo Ricers". I've been using these options on Gentoo linux for approximately 5 years. If they caused problems, I would've found out by now, because almost everything on Gentoo is built from source.

When you do, please make sure you disable official branding. I looked once again over the build config and patches used in aports and they are too far removed from our official config to be accepted with official branding.

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

Moonchild wrote:When you do, please make sure you disable official branding. I looked once again over the build config and patches used in aports and they are too far removed from our official config to be accepted with official branding.

In this case, can we publicly expose build options below?Is disabling official branding just enough or we must rename package and executable names too?

If you don't use official branding, you can use whichever build configuration you like most.You can either continue using the "New Moon" branding which is unofficial and can be used accordingly (see redist point 13 at http://www.palemoon.org/redist.shtml) or you can re-brand it to something you prefer (name+visual marks) like e.g. iceweasel does. The latter has our preference if you intend to maintain your specific fork for a longer time.

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

We're currently continuing on the distro (TAZ) itself.Since future versions of the distro would incorporate newer versions of palemoon, it would be useful that these changes are pulled in, in order to reduce our workload in future versions, but also to give all other gentoo distro's the ability to build palemoon with musl.

VCTLabs' pull request of 16 june 2018 was dismissed by deu at 18 August (https://github.com/deu/palemoon-overlay/pull/66 ).Deu mentioned then that the pull request could instead be done upstream (we'll look into this option).In either case, the pull request would already need an update as we need it to run under gcc 6.4 rather than 7.3.Reason is that this way, we are on the same toolchain as the alpine builds, which Taner Tas has had good results with.In the distro, SJLC solved this gcc issue in palemoon/newmoon by switching the gcc in the seed stage to the older version.

Last edited by Peregrine on Wed, 19 Sep 2018, 15:24, edited 1 time in total.