E.g., USE_GCC mentions 9, because I want this precise version and no other (and, in particular, more recent ones).įor the order of the different Makefile's statement, I mostly followed the guidelines, but found that for some reason, IIRC, no order makes all warnings disappear (I remember suspecting some bug in portlint). Most of them seem moot to me: They describe situations for which what I did is exactly what is intented. (In reply to Kurt Jaeger from comment #4)
#Pale moon 26 removed Patch
WARN: /home/pi/m/It is recommended to use ``make makepatch'' when you need to generate a patch to ensure proper patch format. It is recommended to use ``make makepatch'' when you need to generate a patch to ensure proper patch format. WARN: /home/pi/m/patch was not generated using ``make makepatch''. WARN: Makefile: seems to have unnecessary blank lines at the last part. WARN: Makefile: "USES" has to appear earlier. WARN: Makefile: "BUILD_DEPENDS" has to appear earlier. WARN: Makefile: "LIB_DEPENDS" has to appear earlier. WARN: Makefile: "ONLY_FOR_ARCHS_REASON" has to appear earlier. WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier. WARN: Makefile: Consider defining LICENSE. endif in the case of a conditional)įATAL: Makefile: extra item "UXP_VERSION" placed in the PORTNAME section. Unless you have confirmed this port does not build with later versions of GCC, please use USE_GCC=9+.įATAL: Makefile: the last line of Makefile has to be.
WARN: Makefile: : Setting a specific version for USE_GCC should only be done as a last resort. Use $ instead and set according USE_AUTOTOOLS= macro WARN: Makefile: : possible direct use of command "autoconf213" found. I'll try to provide some when necessary, but prepared to be advised to just drop non-default options if for whatever reason I can't. It can expect no support upstream if not using the default build options.
#Pale moon 26 removed free
Redistribution of binary packages is allowed as long as the default options are not changed with respect to the current ones (if they must, then I would likely have to check with upstream).Īny individual user using the port system is free to change the provided options as he wishes before he builds and retain official branding as long as he doesn't distribute his version. Notwithstanding the fact that the browser and its platform have to be built with GCC whereas the C++ pieces have to be compiled and linked against libc++.įor the record, relevant issues and pull requests upstream: I had to go to the pain of making their in-tree jemalloc bootstrap on FreeBSD, as well as modify the ad-hoc build system (inherited from an old version of Mozilla's) to work with Tauthon, since Python 2.7 is EOL. More precisely, upstream insisted that their in-tree jemalloc be used instead of the system's one, but agreed with the requirement to link against libc++ (since Pale Moon's platform indirectly depends on libraries containing C++ code). Official branding is granted in compliance with Pale Moon's redistributionĬonfirmed by the owner (Moonchild see for the relevant discussion on Pale Moon's forums), since build options were not modified beyond what is necessary to get a stable build on FreeBSD. (And, obviously, please advise if you think the current Makefile is doing things wrong.)Īttaching a patch with the latest version with official branding enabled. So please wait until I confirm that the patch is final before importing into the tree. This is by design, and not bad by principle, and personally I won't dispute this precise case. See the comments in the Makefile (see also bug #211154).Īpart from jemalloc, all bundled libraries are used in preference to our versions in the ports tree. This is necessary since linking against libstdc++ while one of the dependencies is linked to libc++ causes a crash for this codebase. So USE_GCC is set, but then LDFLAGS and CXXFLAGS are appended to in order that g++ links to (base) libc++ (static link against libgcc.a). GCC 9 was chosen since it is our current default and is (almost) officially endorsed upstream (and stability seems perfect so far). The build needs some specific versions of GCC (executables crash with base clang on 12). Small description: "Open-source web browser mostly using Pale Moon(TM) code" I'll post a comment giving the go when the process finishes (the patch may need to be modified before reaching this point). I'm in the process of liaising with upstream in order to verify that there is no branding or redistribution problems with the submitted port.
This port depends on the new Tauthon port I submitted here: bug #251019Įven when this dependency is imported, please *do not import the patch yet*.
#Pale moon 26 removed code
Here is a port of most of Pale Moon code with unofficial branding. Version 29.0.1, -CURRENT build hopefully fixedĢ9.4.3 + GCC/libc++ 13 compilation problem workaround
Version 29.0.1: Patch against the ports tree
0 kommentar(er)
