PaleMoon 25.6.0 build problem on Linux?

[Unix Ronin]

Has anyone been able to successfully compile PaleMoon 25.6.0 on Linux? I tried to update my Gentoo ebuild for PaleMoon today, and the first problem that I can into was that the actual source code was packaged one level deeper than expected, inside Pale-Moon-25.6.0_Release. Once I worked around that, the build went OK up to this point:

Code: Select all

make -C build libs
make[5]: Entering directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu/build'
make -C unix libs
make[5]: *** No rule to make target '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/.gdbinit', needed by '../dist/bin/.gdbinit'.  Stop.
make[5]: *** Waiting for unfinished jobs....
make[6]: Entering directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu/build/unix'
/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu/config/nsinstall -R -m 644 "/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/build/unix/run-mozilla.sh" "../../dist/sdk/bin"
/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu/config/nsinstall -R /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/build/unix/run-mozilla.sh ../../dist/bin
make[6]: Leaving directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu/build/unix'
make[5]: Leaving directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu/build'
/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/config/makefiles/target_libs.mk:16: recipe for target 'libs_tier_base' failed
make[4]: *** [libs_tier_base] Error 2
make[4]: Leaving directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu'
/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/config/rules.mk:723: recipe for target 'tier_base' failed
make[3]: *** [tier_base] Error 2
make[3]: Leaving directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu'
/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/config/rules.mk:656: recipe for target 'default' failed
make[2]: *** [default] Error 2
make[2]: Leaving directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/obj-x86_64-unknown-linux-gnu'
/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/client.mk:372: recipe for target 'realbuild' failed
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory '/var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0'
client.mk:172: recipe for target 'build' failed
make: *** [build] Error 2

...where, as you can see, everything died. Looks like this release may have been built against gdb, which is not a listed dependency.

[squarefractal]

It looks like you're just using the wrong instructions -- try making a normal build using make -f client.mk build && cd $OBJDIR && make package and see if that works.

[Unix Ronin]

It looks like you're just using the wrong instructions -- try making a normal build using make -f client.mk build && cd $OBJDIR && make package and see if that works.

This exact same build procedure has worked for the last 15 or so releases. I was expecting not to have to update anything in my ebuild except the version.

[New Tobin Paradigm]

Off-topic:
Never assume anything.

[Unix Ronin]

Looks like two changes to the ebuild seem to have resolved the problem:

1. Append Pale-Moon-25.6.0_Release to S (source dir) at the end of src_unpack();
2. Change 'emake -f client.mk' to 'emake -f client.mk build' in src_compile().

I'll know in a few more minutes whether the emerge succeeds without further errors, and if it does I'll push it out to my overlay.

[Moonchild]

I'm afraid the source folder has been my mistake. It should not be in the subfolder.
I'll re-pack the source properly tonight and upload it.

To build, you would indeed normally always use the "build" command.
Are you also issuing a "package" command after building to get everything properly stripped and packaged?

[Unix Ronin]

I'm afraid the source folder has been my mistake. It should not be in the subfolder.
I'll re-pack the source properly tonight and upload it.

To build, you would indeed normally always use the "build" command.
Are you also issuing a "package" command after building to get everything properly stripped and packaged?

I've taken over maintenance of a much older ebuild that hadn't updated for a long time. It undoubtedly should have been using the 'build' all along, but wasn't. Gentoo doesn't use the package as such; it does a fake install into a temporary directory, then merges that into the live filesystem.

If you're going to update the source tarball, I'll hold off pushing the ebuild out until after it's updated.

[Moonchild]

The problem is that just issuing "build" and "install" won't give you a proper Pale Moon version. "make -f client.mk package" or "mach package" (if you use mach) strips and copies the necessary additional files, then creates a tarball out of it. That resulting tarball is what you should be using, not the raw build, or you'll be missing e.g. the status bar code (and more things in the future that will be integrated the same way).

The source .7z has been updated and I'm uploading as I write this, should be done by the time this comment is read.

[Unix Ronin]

I'll definitely look into that then. I definitely want to make this ebuild perform the install as correctly as possible. For all I know, that 'make package' step is being done automatically behind the scenes by Portage.

How can I verify whether I'm getting the correct files prepared for merging?

[Moonchild]

I'll definitely look into that then. I definitely want to make this ebuild perform the install as correctly as possible. For all I know, that 'make package' step is being done automatically behind the scenes by Portage.

How can I verify whether I'm getting the correct files prepared for merging?

The easiest would be to check if you have a distribution/bundles/ directory in the resulting application directory where the status bar code lives. If it's missing, then you don't have a properly packaged build since that is added only in the packaging stage.

[Unix Ronin]

OK, the 'install' does not create a distribution/bundles directory. I should be able to run a 'make package' then unpack the package into the fake-install directory.

I'm not seeing a 'package' target in the client.mk file, though 'make package' clearly works and appears to do what it should. I'm trying to look at that target to see what exactly it does. What am I missing...?

[Unix Ronin]

I believe I now have the ebuild Doing The Right Thing, with a little working around. However, it would be a lot cleaner if 'make install' properly installed all the add-ins as well.

I'm also getting the following QA warnings from the build, which appear to be multiple invocations of two instances of the same check:

Code: Select all

 * QA Notice: Package triggers severe warnings which indicate that it
 *            may exhibit random runtime failures.
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:987:17: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:868:15: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:987:17: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:868:15: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:987:17: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:868:15: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:987:17: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]
 * /var/tmp/portage/www-client/palemoon-25.6.0/work/palemoon-25.6.0/gfx/cairo/libpixman/src/pixman-inlines.h:868:15: warning: the comparison will always evaluate as 'true' for the address of 'op_bilinear_over_8888_0565' will never be NULL [-Waddress]

In both cases the check is if (op_func != NULL). This doesn't look to me as though it actually matters, but I thought I'd pass it on.

[Moonchild]

However, it would be a lot cleaner if 'make install' properly installed all the add-ins as well.

It's simply not how the build process is designed. It is designed to always have a packaging step for all operating systems. Consider it a result of designing things for multiple operating systems in a single tree. Pale Moon is primarily not designed on and for Linux flavors, and is not designed for a "make && make install" setup. In older versions this may have worked better but since Mozilla re-did the way the packager works, the raw "bin" file is simply only good for core testdriving but not for final use.

This doesn't look to me as though it actually matters, but I thought I'd pass it on.

Pixman is rather noisy, true. I'm already aware of this, but once again cross-platform use makes it difficult to make it perfectly aligned with every possible target OS.
Similarly, on Windows, you'll be treated to strings of "pkg-config" warnings while building because it doesn't exist.

[Unix Ronin]

However, it would be a lot cleaner if 'make install' properly installed all the add-ins as well.

It's simply not how the build process is designed. It is designed to always have a packaging step for all operating systems. Consider it a result of designing things for multiple operating systems in a single tree. Pale Moon is primarily not designed on and for Linux flavors, and is not designed for a "make && make install" setup. In older versions this may have worked better but since Mozilla re-did the way the packager works, the raw "bin" file is simply only good for core testdriving but not for final use.

Well, the ebuild uses the package step now.

[Moonchild]

Well, the ebuild uses the package step now.

Excellent! Thanks for your work on this

[Lord_Brezel]

Do you have the final ebuild posted somewhere?

[Tony0945]

Do you have the final ebuild posted somewhere?

Also interested. Since this appears to be an officially sanctioned build, could a link be made at http://www.palemoon.org/contributed-builds.shtml ?