FreeBSD compile story

[sefgault]

Hello,

I'm using FreeBSD (for now) and I recently had segfault at start after recompiling Palemoon 28.8.3 which was working before with FreeBSD 12.0 after I switched to 12.1.
I went back to 12.0, recompiled and it's working correctly again.
After investigation, turns out the base compiler changed from clang 6.0.1 to 8.0.1.
I'd like to confirm this by using clang8 on 12.0 and clang6 on 12.1 but the mozconfig option "export CC", "export CXX" doesn't seem to have any effect since it first check correctly for the specified compiler, then it uses the default one. But I'm pretty sure it's the main factor.

The .mozconfig used is pretty much the one suggested for the Linux compilation except not enabling jemalloc (the system one works) and pointing the x-libraries to /usr/local/lib

Also some minor code change:

Code: Select all

diff --git a/ipc/chromium/src/third_party/libevent/evutil_rand.c b/ipc/chromium/src/third_party/libevent/evutil_rand.c
index 7c92bae23..25f086286 100644
--- a/ipc/chromium/src/third_party/libevent/evutil_rand.c
+++ b/ipc/chromium/src/third_party/libevent/evutil_rand.c
@@ -143,7 +143,11 @@ evutil_secure_rng_get_bytes(void *buf, size_t n)
 void
 evutil_secure_rng_add_bytes(const char *buf, size_t n)
 {
+#if defined(__OpenBSD__) || defined(__FreeBSD__)
+       arc4random_buf((unsigned char*)buf,
+#elif
        arc4random_addrandom((unsigned char*)buf,
+#endif
            n>(size_t)INT_MAX ? INT_MAX : (int)n);
 }
 #endif

It's just using "arc4random_buf" instead of "arc4random_addrandom" since it doesn't exist on OpenBSD/FreeBSD
Dunno if it fits the security standard, instead of adding some randomness, a new buffer is created.
And the function is the same whether it's OpenBSD or FreeBSD, there's manual page you can check online; but I can't test compilation on OpenBSD since I don't have a box at hand.

Anyway, peace out.
Somebody else can continue this.

[Moonchild]

Please note that outside of OSX we don't support compiling with clang; you should try building with a supported gcc version (4.9, 5.x, 7.x, or 8.x... 9 -may- work but is experimental. 6 produces unstable binaries in most cases)

[Lunokhod]

I had to redirect gcc from gcc9 to gcc8, first I used /usr/local/bin symlinks (this was a suggestion from StackExchange or Arch forums or something)

Code: Select all

$ sudo ln -s $(which gcc-8) /usr/local/bin/gcc
$ sudo ln -s $(which g++-8) /usr/local/bin/g++
$ sudo ln -s $(which cc-8) /usr/local/bin/cc
$ sudo ln -s $(which c++-8) /usr/local/bin/c++
$ sudo ln -s $(which cpp-8) /usr/local/bin/cpp
$ sudo ln -s $(which gcc-ar-8) /usr/local/bin/gcc-ar
$ sudo ln -s $(which gcc-nm-8) /usr/local/bin/gcc-nm
$ sudo ln -s $(which gcc-ranlib-8) /usr/local/bin/gcc-ranlib
$ sudo ln -s $(which x86_64-pc-linux-gnu-c++-8) /usr/local/bin/x86_64-pc-linux-gnu-c++
$ sudo ln -s $(which x86_64-pc-linux-gnu-g++-8) /usr/local/bin/x86_64-pc-linux-gnu-g++
$ sudo ln -s $(which x86_64-pc-linux-gnu-gcc-8) /usr/local/bin/x86_64-pc-linux-gnu-gcc
$ sudo ln -s $(which x86_64-pc-linux-gnu-gcc-ar-8) /usr/local/bin/x86_64-pc-linux-gnu-gcc-ar
$ sudo ln -s $(which x86_64-pc-linux-gnu-gcc-nm-8) /usr/local/bin/x86_64-pc-linux-gnu-gcc-nm
$ sudo ln -s $(which x86_64-pc-linux-gnu-gcc-ranlib-8) /usr/local/bin/x86_64-pc-linux-gnu-gcc-ranlib
$ hash -r

That worked but so did exporting gcc-8 in .mozconfig:

Code: Select all

export CC=/usr/bin/gcc-8
export CXX=/usr/bin/g++-8
export HOST_CC=/usr/bin/gcc-8
export HOST_CXX=/usr/bin/g++-8

This was in Linux not BSD.

[New Tobin Paradigm]

You shouldn't have to export anything if they are in your path. The Build System would be able to pick it up.

[Lunokhod]

Not sure about BSD, but I guess reading the OP it's a similar problem - in Arch based distros, "gcc" is always the latest version. There's no update-alternatives like in Debian based distros that would link /usr/bin/gcc to /usr/bin/gcc-8 instead of /usr/bin/gcc-9. As standard the Pale Moon build finds gcc, g++ etc. and uses that, so it must be redirected. On Debian I think the "gcc" package just provides the main command names like /usr/bin/gcc and /usr/bin/g++ and you can choose the package of any version of gcc containing the actual compiler to go with it. On Arch gcc is the compiler itself and the usual command names. I think RPM os's might have something similar to Debian too. There's talk of adopting alternatives in Arch in the future.

Code: Select all

$ pacman -Qs gcc
local/gcc 9.2.1+20200130-2 (base-devel)
    The GNU Compiler Collection - C and C++ frontends
local/gcc-libs 9.2.1+20200130-2
    Runtime libraries shipped by GCC
local/gcc8 8.3.0-4
    The GNU Compiler Collection - C and C++ frontends (8.x.x)
local/gcc8-libs 8.3.0-4
    Runtime libraries shipped by GCC (8.x.x)
local/lib32-gcc-libs 9.2.1+20200130-2 (multilib-devel)
    32-bit runtime libraries shipped by GCC
$ ls /usr/bin |ag gcc
gcc
gcc-8
gcc-ar
gcc-ar-8
gccmakedep
gcc-nm
gcc-nm-8
gcc-ranlib
gcc-ranlib-8
winegcc
x86_64-pc-linux-gnu-gcc
x86_64-pc-linux-gnu-gcc-8
x86_64-pc-linux-gnu-gcc-8.3.0
x86_64-pc-linux-gnu-gcc-9.2.1
x86_64-pc-linux-gnu-gcc-ar
x86_64-pc-linux-gnu-gcc-ar-8
x86_64-pc-linux-gnu-gcc-nm
x86_64-pc-linux-gnu-gcc-nm-8
x86_64-pc-linux-gnu-gcc-ranlib
x86_64-pc-linux-gnu-gcc-ranlib-8
$ pacman -Qo /usr/bin/gcc
/usr/bin/gcc is owned by gcc 9.2.1+20200130-2

[Moonchild]

Off-topic:

in Arch based distros, "gcc" is always the latest version. There's no update-alternatives like in Debian based distros that would link

There is a reason we provide Linux binaries (as opposed to some GNU-extremist devs who only supply source code for anything)...

[Walter Dnes]

I'm using FreeBSD (for now) and I recently had segfault at start after recompiling Palemoon 28.8.3 which was working before with FreeBSD 12.0 after I switched to 12.1.
I went back to 12.0, recompiled and it's working correctly again.
After investigation, turns out the base compiler changed from clang 6.0.1 to 8.0.1.

On occasion, I've had to build and use a specific version of GCC on linux. I prefer to install it in a directory like $HOME/gcc540 or whatever. Installing it locally avoids going root/sudo, and everything goes in that directory. No splattering stuff in /usr. "uninstall" is "rm -rf" that directory. This is off-topic, so PM me offline if you want to discuss this further.

[stevenpusser]

Debian's gcc is just a metapackage that will provide the distro's default gcc version. I'm sure Ubuntu follows the same convention. Clang and lld metapackages work the same way:

Description: GNU C compiler
This is the GNU C compiler, a fairly portable optimizing compiler for C.
.
This is a dependency package providing the default GNU C compiler.

Debian really doesn't do backports of newer gcc versions, but with enough effort and compiling time, it can be done: http://mxrepo.com/mx/experimental/pool/test/g/

but I haven't had to worry about Pale Moon for a while in that regard--unlike Telegram-desktop in the past on Stretch.