Repositories for supported Debian, Raspbian, and Ubuntu releases
Moderator: trava90
Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
I'm currently working on 31.1.1, but a little late because I was hit by a pretty bad 48-hr stomach flu on Thursday morning. First i386 and amd64 builds should be appearing on the OBS in a few hours.
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
Off-topic:
Oof! I hope you are feeling better and/or get well soon, Steve!stevepusser wrote: ↑2022-07-09, 18:01I was hit by a pretty bad 48-hr stomach flu on Thursday morning.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
64 and 32-bit x86 builds of 31.2.0 are finishing up on the OBS, as well as arm64 (aarm64).
There appears to be a problem with the armhf (armv71) builds there, however. They are failing with a flurry of errors which are variations on one like this:
here's a zip of one of build logs; the errors start at 7304s.
https://drive.google.com/file/d/1no1oTC ... sp=sharing
There appears to be a problem with the armhf (armv71) builds there, however. They are failing with a flurry of errors which are variations on one like this:
Code: Select all
error: inlining failed in call to always_inline 'vpadd_u8': target specific option mismatch
https://drive.google.com/file/d/1no1oTC ... sp=sharing
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
Looks like a cross-compile issue. Apparently, gcc only allows SIMD intrinsics to be used for instruction sets that are enabled for the compiler to use. i.e. it needs specific simd compiler flags to be passed to gcc for it to allow the use of those intrinsics in code, regardless if you provide the correct headers. That seems like a terrible oversight on gcc's part to me :/stevepusser wrote: ↑2022-08-03, 01:20There appears to be a problem with the armhf (armv71) builds there, however.
Unfortunately I don't have a quick solution there but I'm guessing the build needs to be given specific -m flags on the erroring ARM Neon source code to work (e.g. -mavx or -msse4.1).
EDIT: a quick search gave a hint, maybe you need to specify -mfpu=neon in your config?
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
OK, I assume that will go with the rest of any gcc flags in the mozconfig file.Moonchild wrote: ↑2022-08-03, 04:59Looks like a cross-compile issue. Apparently, gcc only allows SIMD intrinsics to be used for instruction sets that are enabled for the compiler to use. i.e. it needs specific simd compiler flags to be passed to gcc for it to allow the use of those intrinsics in code, regardless if you provide the correct headers. That seems like a terrible oversight on gcc's part to me :/stevepusser wrote: ↑2022-08-03, 01:20There appears to be a problem with the armhf (armv71) builds there, however.
Unfortunately I don't have a quick solution there but I'm guessing the build needs to be given specific -m flags on the erroring ARM Neon source code to work (e.g. -mavx or -msse4.1).
EDIT: a quick search gave a hint, maybe you need to specify -mfpu=neon in your config?
I'll run a test build as a separate package, but it takes many hours to finish. A build error after 7400 seconds on the armhf emulated machine is still near the start of the build, but at least I can see if it gets past that error this afternoon.
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
The test OBS build/gcc rejected this syntax in the mozconfig:
Assume I don't know anything about the syntax, because I don't. How is it supposed to read?
With 31.2.0, I also enabled av1 in the mozconfig per the packager's page example, since I don't have to worry about the problems it had with older gcc versions any longer. I'm running another test build with that disabled for armhf, just in case that caused the problems.
Code: Select all
ac_add_options --enable-optimize="-O2 -Wl -mfpu=neon,--no-keep-memory,--reduce-memory-overhead"
With 31.2.0, I also enabled av1 in the mozconfig per the packager's page example, since I don't have to worry about the problems it had with older gcc versions any longer. I'm running another test build with that disabled for armhf, just in case that caused the problems.
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
--enable-optimize will be literally passed to gcc. I don't think using commas in there is right but I simply don't know enough about the gcc CLI to help you.
I'm assuming space-separated options is what you'd need?
I'm assuming space-separated options is what you'd need?
Code: Select all
ac_add_options --enable-optimize="-O2 -Wl -mfpu=neon --no-keep-memory --reduce-memory-overhead"
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
The comma-separated options is what I had in there before to reduce the memory consumption on 32-bit builds during the final libxul linking, since that was limited to 4 GB, along with the quotes around the whole schmeer. They did work, I just tried guessing where to add the extra flag. I do remember someone writing a while back that future releases shouldn't eat up as much RAM during linking, but don't know if we are there yet.
I did find this additional thing to worry about in the "gcc ARM flags":
I did find this additional thing to worry about in the "gcc ARM flags":
If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations are not generated by GCC’s auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
Can't really help you there, nor do I know in what way that would impact Pale Moon (or if it's significant for a browser? We're not making scientific applications here...)
Also it seems to that gcc will simply skip one compiler optimization if using Neon and use FP emulation for it. So trading off some performance for accuracy. At least that's what I read there.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
OK, I found out how to pass those gcc flags from the debian/rules file, and also how to have those particular flags only passed on autodetected armhf builds, so here's the complete set of flags in the ongoing test build on the OBS. Debian's debhelper automatically adds flags, which is probably why there are so many:
The -Wl,--no-keep-memory,--reduce-memory-overhead flags are to reduce memory use during linking after the compile is finished...
Code: Select all
BUILD=. -fstack-protector-strong -Wformat -Werror=format-security -mfpu=neon -funsafe-math-optimizations -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pipe -pthread -g -O2 -Wl,--no-keep-memory,--reduce-memory-overhead -fomit-frame-pointer -Wno-error=shadow
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
armhf builds succeeded for Debian 10, 11, Ubuntu 20.04, 21.10, and 22.04. Failed: Raspian 10, 11, and Debian testing and Sid. All managed to get through the actual compile--the ones that failed died during the final linking when ld threw out errors about "undefined references to blah blah blah".
What's annoying is that Raspian 10 and 11 are supposed to be equivalent to Debian 10 and 11, so I would expect those builds to also succeed. As a workaround, Raspian users can use the matching successful Debian armhf repo.
I'd try building the Debian testing and Sid versions on gcc-10 instead of 11 to see if that helps, except Ubuntu builds fine with gcc-11.
What's annoying is that Raspian 10 and 11 are supposed to be equivalent to Debian 10 and 11, so I would expect those builds to also succeed. As a workaround, Raspian users can use the matching successful Debian armhf repo.
I'd try building the Debian testing and Sid versions on gcc-10 instead of 11 to see if that helps, except Ubuntu builds fine with gcc-11.
- FranklinDM
- Add-ons Team
- Posts: 582
- Joined: 2017-01-14, 02:40
- Location: Philippines
- Contact:
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
stevepusser wrote: ↑2022-08-05, 20:07the ones that failed died during the final linking when ld threw out errors about "undefined references to blah blah blah".
Off-topic:
Oddly enough, I'm currently encountering a similar issue on gcc-11 after updating to Ubuntu 22.04. This wasn't the case back in u20.04 as I was able to build and run without any problems there. I've tried gcc-10 and it threw a warning at the same point as well, with the following message:
This was on the master branch, which is why I doubt that the changes in my own dev branch caused this. The resulting binaries crashed immediately, so I'm now rebuilding with the recommended gcc-9 version. It does take an hour or so to complete, but I'm hoping that it will compile just fine now (fingers crossed).
Another thing is I'm not entirely sure if I'm doing it right in specifying the GCC version to be used. I added the following to my mozconfig:
Oddly enough, I'm currently encountering a similar issue on gcc-11 after updating to Ubuntu 22.04. This wasn't the case back in u20.04 as I was able to build and run without any problems there. I've tried gcc-10 and it threw a warning at the same point as well, with the following message:
Code: Select all
/usr/bin/ld: warning: ../../../../platform/toolkit/library/StaticXULComponents.ld contains output sections; did you forget -T?
Another thing is I'm not entirely sure if I'm doing it right in specifying the GCC version to be used. I added the following to my mozconfig:
Code: Select all
export CC=gcc-9
export CXX=g++-9
export CPP=cpp-9
export LD=gcc-9
- athenian200
- Contributing developer
- Posts: 1536
- Joined: 2018-10-28, 19:56
- Location: Georgia
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
I've produced successful builds on newer Linux that all throw that warning during the build. I also know why it is produced (it's supposed to contain those), so that shouldn't be a major issue.FranklinDM wrote: ↑2022-08-06, 03:28Off-topic:
Oddly enough, I'm currently encountering a similar issue on gcc-11 after updating to Ubuntu 22.04. This wasn't the case back in u20.04 as I was able to build and run without any problems there. I've tried gcc-10 and it threw a warning at the same point as well, with the following message:Code: Select all
/usr/bin/ld: warning: ../../../../platform/toolkit/library/StaticXULComponents.ld contains output sections; did you forget -T?
These two lines seem correct, but..export CC=gcc-9
export CXX=g++-9
These two, do not seem right. "CPP" is not a separate thing as far as I know. And LD is a separate program from GCC. The two main linkers that get used on Linux are gold and and bfd, and some also use the lld linker from LLVM. Some newer distros make "gold" the default ld, and put bfd under ld.bfd.export CPP=cpp-9
export LD=gcc-9
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind
- jobbautista9
- Keeps coming back
- Posts: 784
- Joined: 2020-11-03, 06:47
- Location: Philippines
- Contact:
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
Hmm, that's interesting. I also did gcc-11, as well as gcc-12, and while they both gave me the same warning at the linking of libxul, I didn't get any crashes on runtime. I'm on the testing branch of Devuan GNU/Linux. I also only export CC and CXX, so the CPP and LD exports might cause issues for you.
merry mimas
XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.
Mima avatar by 絵虎. Pixiv post: https://www.pixiv.net/en/artworks/15431817
- FranklinDM
- Add-ons Team
- Posts: 582
- Joined: 2017-01-14, 02:40
- Location: Philippines
- Contact:
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
I've removed the CPP and LD exports from my mozconfig, re-cloned the UXP and Epyrus repositories, and am now building again. If the resulting binaries still crash, I think I'll just have to reinstall Ubuntu from scratch and perhaps try out CentOS 7 as well, while I'm at it.
- athenian200
- Contributing developer
- Posts: 1536
- Joined: 2018-10-28, 19:56
- Location: Georgia
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
I'm in the process of setting up an Ubuntu 22.04 test machine and seeing if UXP builds/runs at all on that OS. If it does, then perhaps a reinstall might be in order. But if not, then it probably wouldn't help.FranklinDM wrote: ↑2022-08-06, 05:25I've removed the CPP and LD exports from my mozconfig, re-cloned the UXP and Epyrus repositories, and am now building again. If the resulting binaries still crash, I think I'll just have to reinstall Ubuntu from scratch and perhaps try out CentOS 7 as well, while I'm at it.
EDIT: The build was successful with GCC 11 and default linker settings for me.
Just to rule something out... do the official binaries of Pale Moon or Epyrus work for you on there, or is it just your builds that crash instantly on newer Ubuntu? I remember some reports that our builds don't work out of the box on there for people with certain video card drivers, and it was after they updated that they started running into this problem. So this might not be a development issue at all.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind
- FranklinDM
- Add-ons Team
- Posts: 582
- Joined: 2017-01-14, 02:40
- Location: Philippines
- Contact:
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
Yes, official binaries for both applications work (I'm currently using stevepusser's GTK2 build to write this post), including those that I've built in the older Ubuntu 20.04. I've been able to compile and it doesn't crash anymore - however, no window shows up and top says that it's eating ~15% CPU in the background doing nothing. The console messages after executing mach run doesn't provide anything useful:athenian200 wrote: ↑2022-08-06, 05:42Just to rule something out... do the official binaries of Pale Moon or Epyrus work for you on there, or is it just your builds that crash instantly on newer Ubuntu?
Code: Select all
frank@frank:/projects/uxp/epyrus$ ./mach run
0:00.55 /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/epyrus -no-remote -profile /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/tmp/scratch_user
[calBackendLoader] Using Thunderbird's builtin libical backend
GDB backtrace:
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
What is the difference between the Raspbian and Debian versions anyway? Before there were Raspbian 11 versions available, I always used the Debian 11 Palemoon package on Raspbian 11.stevepusser wrote: ↑2022-08-05, 20:07armhf builds succeeded for Debian 10, 11, Ubuntu 20.04, 21.10, and 22.04. Failed: Raspian 10, 11, and Debian testing and Sid.
What's annoying is that Raspian 10 and 11 are supposed to be equivalent to Debian 10 and 11, so I would expect those builds to also succeed. As a workaround, Raspian users can use the matching successful Debian armhf repo.
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
As far as I know, they should be equivalent. Raspian does leave off certain Qt 5 packages that Debian includes, https://forums.raspberrypi.com/viewtopic.php?t=320031
which caused problems when I built Stellarium armhf packages on Debian armhf that ended up depending on runtimes that aren't in Raspian, but Raspian users were able to just installing the missing debs from the Debian repo, and then it worked fine.
But that doesn't affect Pale Moon builds.
which caused problems when I built Stellarium armhf packages on Debian armhf that ended up depending on runtimes that aren't in Raspian, but Raspian users were able to just installing the missing debs from the Debian repo, and then it worked fine.
But that doesn't affect Pale Moon builds.
- Pentium4User
- Board Warrior
- Posts: 1133
- Joined: 2019-04-24, 09:38
Re: Repositories for supported Debian, Raspbian, and Ubuntu releases
Ubuntu 21.10 can be removed, EoL.
The profile picture shows my Maico EC30 E ceiling fan.