Pale Moon forum

I'm in the process of updating my unofficial Gentoo ebuild for PaleMoon from 27.7.2 to 27.8.0, and I'm running into a few problems at the configuration stage. Configure seems to be objecting principally to two things:

1. sys/int_types.h doesn't exist; one of the source header files referencing it, netwerk/srtp/src/crypto/include/integers.h, says it exists on SunOS, but this isn't SunOS, so I'm not clear why configure considers it a fatal error that it doesn't exist on Linux.

2. Configure is also reporting a branding error which it now apparently considers a fatal error. What do I need to do about this in order to be compliant here? I am doing my level best to make this as faithful and "untouched" a build as possible, and I am making no code changes whatsoever.

What compiler are you building it against?

This is probably a result of what happened on the BSD side of things. Are you compiling with any of the system-wide libs enabled? It will now refuse to compile if you also have branding enabled. Either disable the one or the other. If you disable branding, though, you'll get "New Moon".

You can satisfy the branding issue by adding an ac option to your mozconfig: "--enable-private-build"
This will bypass the branding requirements but will obviously not be allowed to be used for redistributed builds or build overlays that are not privately built.

If your gentoo ebuild will be used by others than yourself you have to make the build compliant with our building guidelines, specifically not using --with-system-xxx or --enable-system-xxx for our in-tree libraries and other non-official build configurations, or, as stated, not use --enable-official-branding. Please see our wiki entries for building on Linux which has a good starting point .mozconfig that you should not deviate significantly from for official builds.

OK, I've revised the logic in the ebuild and added some additional configuration USE flags to allow disabling all system library options (and all are disabled by default) EXCEPT system-libvpx (more on that below). Enabling any system-X USE flag or USE=bindist now automatically sets --disable-official-branding.

With official branding disabled, it builds (and, now, installs) successfully,

I have not found any working mozconfig invocation to disable system-libvpx, and the initial configuration phase appears to be telling me that system-libvpx is required anyway. As far as I can figure out, I CANNOT disable it. Am I understanding this correctly> Should I be trying to allow disabling system-libvpx? With official branding enabled but all system libraries [theoretically] disabled, but --with-system-libvpx still showing as "required", I still run into the sys/int_types.h problem and still get a branding violation . I haven't been able to determine what is still causing the violation unless it is system-libvpx. Here's what configure is returning:


==========================================================
Building palemoon-27.8.0 with the following configuration
--enable-application=browser mozilla.org default
--enable-optimize mozilla default
--with-default-mozilla-five-home=/usr/lib64/palemoon-27.8.0 mozilla.org default
--disable-updater disable_update_strip
--disable-strip disable_update_strip
--disable-install-strip disable_update_strip
--enable-default-toolkit=cairo-gtk2 mozilla.org default
--enable-official-branding +!bindist
--disable-dbus -dbus
--disable-debug -debug
--disable-tests -debug
--disable-debug-symbols disabled by Gentoo
--disable-startup-notification -startup-notification
--disable-system-sqlite -system-sqlite
--disable-necko-wifi -wifi
--enable-ogg required
--enable-wave required
--with-system-libvpx required
--x-includes=/usr/include mozilla.org default
--x-libraries=/usr/lib64 mozilla.org default
--with-system-libevent=/usr mozilla.org default
--enable-system-hunspell mozilla.org default
--disable-gnomevfs mozilla.org default
--disable-gnomeui mozilla.org default
--enable-gio mozilla.org default
--disable-crashreporter mozilla.org default
--prefix=/usr mozilla.org default
--libdir=/usr/lib64 mozilla.org default
--enable-extensions=default mozilla.org default
--disable-gconf mozilla.org default
--disable-mailnews mozilla.org default
--disable-accessibility mozilla.org default
--disable-parental-controls mozilla.org default
--disable-webrtc mozilla.org default
--disable-logging mozilla.org default
--enable-websms-backend mozilla.org default
--with-default-mozilla-five-home=/usr/lib64/palemoon-27.8.0 mozilla.org default
--target=x86_64-pc-linux-gnu mozilla.org default
--build=x86_64-pc-linux-gnu mozilla.org default
--enable-gstreamer mozilla.org default
--disable-pulseaudio mozilla.org default
--enable-ion +jit
==========================================================


Note that this is after configuring with an explicit mozconfig_annotate '' --without-system-libvpx.

Any advice here?

One.. Your mozconfig is insane.
Two. ac_add_options --enable-private-build will bypass branding restrictions.
Three. What the hell are you even doing? Use deu's overlay or follow the wiki. Where did you get these configure flags.. Some of them don't exist and some of them haven't been valid for the codebase outside comm-central split since 2009.. Seriously.

Oh, wait, I just spotted it's using system libevent. Let me see if I can disable that...

Updated my post above.. Read it and respond.

BTW this is WHY Configure Variable Verification exists. You clearly don't know what you are doing.

Uh, at the time I created my ebuild there was no overlay with a current Pale Moon ebuild. Thanks for pointing out deu's. If that is both current and endorsed I am totally happy to use that instead.

I would appreciate an explanation of Configure Variable Verification. No, I freely admit to not being anywhere close to expert either with Pale Moon or with Gentoo ebuilds, but I'm trying to learn as much as I can.

First and foremost it is to protect our brand integrity from overzealous packagers that just apply some random mozconfig they picked up off the internet somewhere or use Firefox's straight up. Additionally, it can be an indicator of a misconfigured build such as your situation is.

Generally speaking for best results you shouldn't use much more than http://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux#head:Mozconfig_Files. Less is definitely better in the case of a mozconfig file. Most things are already set to their defaults except things that would be platform specific and a few other bits and bobs. Many of our configure flags have been reversed from what they were over at Mozilla.

Remember, just because you CAN set something doesn't mean it is a good idea.

...OK, I've added deu's overlay, but I note that every palemoon release in it is hard-masked. Also, I see that deu's build supports only gcc-4.7 and 4.9. This is unbuildable on Gentoo profile 17.x, which requires gcc-6.4.0 for systemwide ASLR. So I'm going to have to see if it has any issues with allowing 6.4 (I haven't run into any problems with Pale Moon 27 and gcc-6.4).

I originally adapted my ebuild from Firefox's, but I've been working since then to try to clean it up and clean out cruft — just like Pale Moon has been clearing out Firefox cruft — including a major cleanup for 27.x, and taking all the help I could get along the way. But I wouldn't have had to do any of this if I could have found a current package from the start. I did find one overlay containing Pale Moon when I first switched, and at the time I used that overlay, but it was outdated and eventually abandoned, so I had no choice but to roll my own.

(Footnote: I just spotted the note about the PALEMOON_ENABLE_UNSUPPORTED_COMPILERS variable.)

GCC 5 can be unstable.. GCC 6 is really a no go. Not for Tycho.

Tycho is the codename for 27.8?

Unix Ronin wrote:Tycho is the codename for 27.8?

The whole 27.x line yeah.. Sorry, I tend to specifically differentiate when we have multiple codebases going..

OK. I'm actually chatting with deu about this right now. The interesting detail right now is that I can build 27.7.2 or 27.8.1 from deu's ebuild and it compiles, but SEGVs moments after starting; I stopped work on my 27.8 update when you pointed out deu's, but I can build 27.7.2 with gcc-6.4.0 from my 27.7.2 ebuild and it works fine. The official 27.8.1 palemoon binary package, I have discovered, also works fine.

I'm just going to switch to use the binary package for the time being, but in the meantime we've spent the day trying to figure out what is different that is causing one builld to SEGV and the other, not. No real conclusions so far unfortunately.

I am more than slightly irritated to find that by all appearances, my 27.7.x ebuild was working when compiled with gcc-6.4.0 by sheer dumb luck.

Unix Ronin wrote:I'm just going to switch to use the binary package for the time being, but in the meantime we've spent the day trying to figure out what is different that is causing one builld to SEGV and the other, not. No real conclusions so far unfortunately.

I am more than slightly irritated to find that by all appearances, my 27.7.x ebuild was working when compiled with gcc-6.4.0 by sheer dumb luck.

Delayed response after getting 27.8.1 SSE out. As a test, I built Pale Moon master (unstable) today natively on my 32-bit Gentoo with gcc-6.4, instead of in the CentOS 6.5 chroot with gcc-4.9. It appears to run fine. When I first attempted to build Pale Moon a long time ago, I ran into mysterious flakiness and crashes. Digging deep into the build log, I found error messages about not having permission to execute a few scripts. This was probably a holdover from Pale Moon's days as a Windows-only project, and no worries about script permissions. I put the command chmod -R 755 pmsrc/ (pmsrc/ is the source directory) into my robo-builder script, and things have sailed along smoothly ever since.

What may be happening is that a few scripts are not executing during configuration, and you're not getting a full build. Try it; it's helped me. It might even help your libvpx problem.

Script permissions have been fixed a long time ago already -- if you make sure to grab the tar.gz archive or use a git checkout, you should be fine on that.

I've mentioned this issue a few times in the past. I didn't keep repeating over and over to avoid looking like I'm nagging. I'm not a C/C++ programmer, but I'm competent at bash...
Files listed in z2.txt are executable, those in z1.txt are not. The first line in z1.txt is
pmsrc/security/nss/fuzz/config/clone_libfuzzer.sh
The first line in z2.txt is
pmsrc/b2g/confvars.sh
Note the difference in permissions. z1.txt lists 59 hits. That's just the .sh files. What about .ksh files and .py files, and who knows what else that should be executable? Doing a global chmod on the source is a heavy-handed solution but it works. Note; it's been a long time since I previously did this check manually; I have the chmod command in my robo-builder script. I've mentioned this issue a few times in the past, and I didn't want to cross the line into nagging.

As Moonchild mentioned I'm certain this was fixed quite some time back, and I myself have not experienced any such issues (either from git checkout or downloading the tar.gz archive).