Package: gnuzilla;
Message #8 received at 73093 <at> debbugs.gnu.org (full text, mbox):
From: bill-auger <bill-auger <at> peers.community> To: Nin Gen <0xningen <at> gmail.com> Cc: 73093 <at> debbugs.gnu.org Subject: Re: bug#73093: Shouldn't Icecat should be moving to the 128.x.x branch? Date: Mon, 16 Sep 2024 01:06:19 -0400
you may not need LLVM/clang - GCC also works most of the time - both will
often fail depending on the version, arch, and available dependencies - in some
cases, only LLVM can compile mozilla; and in some cases, only GCC can - it is
one of those cases so often that the parabola mozilla PKGBUILDs ('iceweasel',
icecat', 'icedove', etc) have switches to quickly swap compilers and linkers
from https://git.parabola.nu/abslibre.git/tree/libre/icecat/PKGBUILD
if (( _USE_ALT_COMPILER ))
then cat >> ../mozconfig <<END
export CC=gcc
export CXX=g++
export AR=gcc-ar
export NM=gcc-nm
export RANLIB=gcc-ranlib
END
fi
if (( _USE_ALT_LINKER ))
then sed -i '/cargo_rustc_flags += -Clto/d' config/makefiles/rust.mk
cat >> ../mozconfig <<END
ac_add_options --disable-linker=lld
ac_add_options --enable-linker=bfd
ac_add_options --disable-lto
ac_add_options --disable-rust-simd
ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
END
fi
with one known caveat: for v128 and later, the behavior of $_SKIP_PGO in the
parabola PKGBUILD (skip the PGO build stage) will also be necessary when
$_USE_ALT_COMPILER and the --enable-profile-generate=cross options are both
enabled
> ac_add_options --enable-profile-generate=cross
->
> ERROR: Cannot use cross-language PGO with GCC.
so the current 'iceweasel' PKGBUILD (and the next 'icecat' PKGBUILD) define
_SKIP_PGO to account for that
> readonly _SKIP_PGO=$(
> case "${CARCH}" in
> armv7h|i686) echo 1 ;;
> *) echo ${_USE_ALT_COMPILER} ;;
> esac
> )
On Sat, 7 Sep 2024 01:13:22 +0000 Nin wrote:
> the current version of clang/llvm is 18 which seems not backwards compatible
o/c it may not be forward-compatible either - this is a general concern which
all distros must manage routinely - it is typical of software like mozilla,
which supports it's deps so narrowly, releases too often, and has the public
convinced they they must always be running the latest _upstream_ release
- for example, the current LLVM in debian and trisquel is v14, which means that
rolling distros could compile icecat 128; but LTS distros (the greatest
user-base) could not compile it, even if it was ready
the version of LLVM in the distro repos (or any other build dep) is as likely
to be too new as it is to be too old - i think that mozilla targets the latest
ubuntu, which means that LTS distros (eg: debian, trisquel) will normally have
older versions of build deps than the ones tested against by mozilla; and
rolling distros (eg: arch, parabola, guix) will normally have newer versions of
build deps than those mozilla used - the build deps may be incompatible for
either reason; though both use-cases are equally common and legitimate - at any
point in time, it is probably not possible to easily compile every release of
any mature software on every distro - generally, upstreams favor LTS distros
in such cases
> the current version of clang/llvm is 18
feel free to ignore the remainder of this message - it is just to unpack
"the current version" as an absolute concept - that requires a relative
qualifier at least - it is important to dispel the "current" qualifier WRT
compilers - it breaks-down to:
* the version of LLVM currently available in repos of rolling distros is v18
* the version of LLVM currently available in repos of LTS distros is v14
* the version of LLVM required by mozilla v115+ is v17+
which suggests the more refined question, to answer "Shouldn't Icecat should be
moving to the 128.x.x branch?":
* which distros should gnuzilla support, given that some distros are often
or always unable to compile the latest versions of mozilla?
generally, the latest upstream release of any software is _not_ the one which
users should consider as "the current version"; because some releases
(regardless of age) are likely to be be incompatible with the distro - that is
to be expected; and distro packagers always work within that constraint - the
"current version", as it is actually relevant to the distro packager and users,
is the version currently in the distro repos, which is usually _not_ the latest
upstream version - also, some projects maintain multiple "current versions" in
tandem (eg: firefox, linux, ruby, jack); so distro repos may include multiple
versions of the same software, which are all denoted as "current" upstream -
in other words, "the current version of 'foo'" is not a useful concept for
distribution or for users - that is meaningful to the upstream (bug reporting,
etc) - for each given target OS, the important factor is "the compatible
version of 'foo'" (which versions of 'foo' are compatible with my distro?)
so generally, the latest version upstream is not necessarily the one that any
distro or distro user wants or can make use of - as an extreme example: as
gnuzilla no longer makes releases, the actual "current version" of icecat is
v67 (the last release, from 2019) - in this case, no one wants to use the
actual "current version" of icecat - all users today are running pre-releases;
and that is actually preferable in this rare case
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.