Page 1 of 1
Building fails with glibc 2.36
Posted: 2022-08-02, 05:47
by micwoj92
Builds fine using glibc 2.35, im using gcc 12.1
Pale Moon version 31.1.1, also tried tag 31.2.0.
Code: Select all
38:39.89 In file included from /home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/evutil_rand.c:104,
38:39.89 from /home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/ipc/chromium/src/third_party/Unified_c_src_third_party0.c:101:
38:39.89 /home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/./arc4random.c:486:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration
38:39.90 486 | arc4random_buf(void *_buf, size_t n)
38:39.90 | ^~~~~~~~~~~~~~
38:39.90 In file included from /home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/dist/system_wrappers/stdlib.h:3,
38:39.90 from /home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/buffer.c:69,
38:39.90 from /home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/ipc/chromium/src/third_party/Unified_c_src_third_party0.c:2:
38:39.90 /usr/include/stdlib.h:542:13: note: previous declaration of ‘arc4random_buf’ with type ‘void(void *, size_t)’ {aka ‘void(void *, long unsigned int)’}
38:39.90 542 | extern void arc4random_buf (void *__buf, size_t __size)
38:39.90 | ^~~~~~~~~~~~~~
38:40.22
38:40.22 In the directory /home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/ipc/chromium/src/third_party
38:40.22 The following command failed to execute properly:
38:40.22 /usr/bin/gcc -std=gnu99 -o Unified_c_src_third_party0.o -c -I/home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/dist/system_wrappers -include /home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DHAVE_CONFIG_H -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party -I/home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/ipc/chromium/src/third_party -I/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party/libevent -I/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/compat -I/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/include -I/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/linux -I/home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/dist/include -I/home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/dist/include/nspr -I/home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/dist/include/nss -fPIC -include /home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/mozilla-config.h -DMOZILLA_CLIENT -MD -MP -MF .deps/Unified_c_src_third_party0.o.pp -O2 -Wno-format-overflow -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=multistatement-macros -flifetime-dse=1 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-strict-aliasing -fno-math-errno -pipe -msse2 -mfpmath=sse -pthread -g -O2 -w -fomit-frame-pointer /home/micwoj92/Documents/palemoon-gtk3/src/pmbuild/ipc/chromium/src/third_party/Unified_c_src_third_party0.c
38:40.22 make[5]: *** [/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/config/rules.mk:854: Unified_c_src_third_party0.o] Error 1
38:40.23 make[5]: *** Waiting for unfinished jobs....
38:42.69 make[4]: *** [/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/config/recurse.mk:71: ipc/chromium/src/third_party/target] Error 2
38:42.70 make[4]: *** Waiting for unfinished jobs....
39:20.98 liblayout_xul_grid.a.desc
39:44.24 libdom_indexedDB.a.desc
41:05.16 libdom_canvas.a.desc
41:58.44 libdom_bindings.a.desc
44:02.60 libgfx_skia.a.desc
44:02.70 make[3]: *** [/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/config/recurse.mk:33: compile] Error 2
44:02.70 make[2]: *** [/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/platform/config/rules.mk:494: default] Error 2
44:02.71 make[1]: *** [/home/micwoj92/Documents/palemoon-gtk3/src/Pale-Moon/client.mk:406: realbuild] Error 2
44:02.71 make: *** [client.mk:164: build] Error 2
44:02.74 0 compiler warnings present.
44:02.79 Notification center failed: Install the python dbus module to get a notification when the build finishes.
Re: Building fails with glibc 2.36
Posted: 2022-08-02, 10:08
by athenian200
Well, glibc added
arc4random_buf finally, and that's why we're getting this problem.
https://savannah.gnu.org/forum/forum.php?forum_id=10216
I encountered this before on SunOS because
arc4random_buf is defined in the system headers. I can't seem to find a Linux distro that comes with glibc 2.36 yet, would I have to compile it from scratch to test it?
https://xref.palemoon.org/goanna-centra ... ndom.c#484
I'm thinking the solution is probably to add another ifdef that excludes this code from being compiled at all if the glibc minor version is 36 or greater. There's a possibility that won't work if the code depends on arc4random_buf having a different definition than what glibc put in their headers though. In that case, you could try conditionally doing something like:
So that the definition in the headers doesn't interfere.
Re: Building fails with glibc 2.36
Posted: 2022-08-02, 10:18
by micwoj92
Arch Linux has it in testing repos, probably will be core in around a week or two.
Re: Building fails with glibc 2.36
Posted: 2022-08-02, 11:41
by vannilla
athenian200 wrote: ↑2022-08-02, 10:08
There's a possibility that won't work if the code depends on arc4random_buf having a different definition than what glibc put in their headers though.
The error message says that in the platform code it's defined as
arc4random_buf(void *_buf, size_t n) while in the glibc headers it's
extern void arc4random_buf (void *__buf, size_t __size), so I believe that it shouldn't be a problem. Since these functions are taken from BSD I doubt compatibility code for systems without them are going to have different signatures and certainly glibc is not going to change them (if anything they'll add a glibc-specific alternative with a different signature).
Re: Building fails with glibc 2.36
Posted: 2022-08-02, 13:39
by Moonchild
Of note, it would help in the future to actually include the error message when you post a log output. yours starts just below it with a location.
But yeah looks like it'll just need a conditional based on glibc version to either grab that from glibc or using our in-tree one, depending - the signature [void ptr, size_t] is the same so shouldn't be an issue... assuming the glibc implementation isn't using a differently-behaving piece of code that returns incompatible data...
Re: Building fails with glibc 2.36
Posted: 2022-08-02, 22:38
by micwoj92
I thought it will take much longer, but now 2.36 is in main repos
Moonchild wrote: ↑2022-08-02, 13:39
Of note, it would help in the future to actually include the error message when you post a log output. yours starts just below it with a location.
Sorry, I thought that that what was posted was the error.
Moonchild wrote: ↑2022-08-02, 13:39
But yeah looks like it'll just need a conditional based on glibc version to either grab that from glibc or using our in-tree one, depending - the signature [void ptr, size_t] is the same so shouldn't be an issue... assuming the glibc implementation isn't using a differently-behaving piece of code that returns incompatible data...
Would it be hard to implement? Because now it is impossible to build Pale Moon on Arch, and soon other distros too.
Re: Building fails with glibc 2.36
Posted: 2022-08-02, 23:31
by andyprough
athenian200 wrote: ↑2022-08-02, 10:08
you could try conditionally doing something like:
So that the definition in the headers doesn't interfere.
I'm not following you. Would this be an option in .mozconfig?
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 01:43
by athenian200
andyprough wrote: ↑2022-08-02, 23:31
I'm not following you. Would this be an option in .mozconfig?
No, this would have to be done in the code, and it was one of two possible workarounds. It's a preprocessor directive.
I was hoping the guy who reported the bug would be able to potentially use that information.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 03:28
by andyprough
athenian200 wrote: ↑2022-08-03, 01:43
No, this would have to be done in the code, and it was one of two possible workarounds. It's a preprocessor directive.
I was hoping the guy who reported the bug would be able to potentially use that information.
Oh, so you would add that to the platform/config/system-headers file and recompile?
I'm just curious about how this all works.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 03:52
by athenian200
andyprough wrote: ↑2022-08-03, 03:28
Oh, so you would add that to the platform/config/system-headers file and recompile?
I'm just curious about how this all works.
Ah, I see. Glad to see interest.
I really should have made my point a bit clearer... I'm talking about trying a fix like this. We currently have this code in this file (under libevent) causing the issue, notice the XP_SOLARIS ifdef here:
https://xref.palemoon.org/goanna-centra ... ndom.c#484
My proposed solutions would look something like this:
Solution 1: Just don't build this code on Linux either, following what I did for Solaris.
Code: Select all
#if defined(_we_have_arc4random_buf) || !defined(XP_SOLARIS)
#if (__GLIBC__ <= 2 && __GLIBC_MINOR__ < 36) || !defined(XP_LINUX)
ARC4RANDOM_EXPORT void
arc4random_buf(void *_buf, size_t n)
{
unsigned char *buf = _buf;
_ARC4_LOCK();
arc4_stir_if_needed();
while (n--) {
if (--arc4_count <= 0)
arc4_stir();
buf[n] = arc4_getbyte();
}
_ARC4_UNLOCK();
}
#endif
#endif
Solution 2: Undefine
arc4random_buf so this code can use its own definition on Linux.
Code: Select all
#if defined(XP_LINUX) && (__GLIBC__ >= 2 && __GLIBC_MINOR__ >= 36)
#undef arc4random_buf
#endif
#if defined(_we_have_arc4random_buf) || !defined(XP_SOLARIS)
ARC4RANDOM_EXPORT void
arc4random_buf(void *_buf, size_t n)
{
unsigned char *buf = _buf;
_ARC4_LOCK();
arc4_stir_if_needed();
while (n--) {
if (--arc4_count <= 0)
arc4_stir();
buf[n] = arc4_getbyte();
}
_ARC4_UNLOCK();
}
#endif
The only reason I'm not testing this now is because there aren't any Linux distros I have experience with shipping glibc 2.36 and it would be easier to wait for a beta version of Fedora 37 if I have to do the work myself.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 04:07
by micwoj92
Sorry it took so long, I have to use my "I'm not a programmer" card. I tried using #undef arc4random_buf I also tried using that code posted in previous post in arc4random.c, but it also didn't work for me.
What did work is just to comment out lines 484 to 498 in arc4random.c.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 04:11
by athenian200
micwoj92 wrote: ↑2022-08-03, 04:07
Sorry it took so long, I have to use my "I'm not a programmer" card. I tried using #undef arc4random_buf I also tried using that code posted in previous post in arc4random.c, but it also didn't work for me.
What did work is just to comment out lines 484 to 498 in arc4random.c.
Well, commenting out the lines should work fine as a temporary measure (though we won't accept that upstream, you can do it locally), until we can fix this properly. Those ifdefs are effectively attempting to conditionally comment out code in specific situations, in this case not building the code if we're on Linux with glibc 2.36. I haven't really used those defines before and I may be getting their usage wrong.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 04:44
by Moonchild
Code: Select all
error: static declaration of ‘arc4random_buf’ follows non-static declaration
Can't we just define arc4random_buf as non-static to fix this? That way it can be redefined at will. I'm assuming the glibc variant is non-static.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 04:44
by jobbautista9
@micwoj92 Just curious, does the latest Firefox build for you with glibc 2.36? I've looked at AUR and bugzilla and there doesn't seem to be anyone complaining about it. Mozilla doesn't seem to do any ifdefs here in the same arc4random.c file:
https://xref.palemoon.org/mozilla-centr ... ndom.c#487
If it works, then I wonder if we could just solve this issue by updating the libevent source instead (and re-adding the Solaris check after that). We have a reference in bugzilla for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1766848
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 04:49
by micwoj92
I didn't attempt firefox because it would take ages on my current machine. I think I did something wrong with copy pasting because i think that now Solution 1 from athenian200 seems to work. I will do clean build and report here in like 1-2 hours.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 04:55
by athenian200
Well, usually on Solaris at least, builders patch that locally and don't submit it upstream. Also, glibc 2.36 is so new that Fedora doesn't even have a beta build of it yet. Our codebase builds fine on Fedora 36 with glibc 2.35, I just tested that actually.
The thing is, it's part of ipc, and I don't think we use IPC all that heavily in the first place...
Like, honestly I think a lot of that IPC code is dead or barely used. It's pulling in third-party libraries used by part of an ancient version of Chromium there. So it might be worth seeing how much of it we actually need to begin with before we update Chromium's third-party libs for IPC when we're not multiprocess.
Re: Building fails with glibc 2.36
Posted: 2022-08-03, 06:44
by micwoj92
athenian200 wrote: ↑2022-08-03, 03:52
Code: Select all
#if defined(_we_have_arc4random_buf) || !defined(XP_SOLARIS)
#if (__GLIBC__ <= 2 && __GLIBC_MINOR__ < 36) || !defined(XP_LINUX)
ARC4RANDOM_EXPORT void
arc4random_buf(void *_buf, size_t n)
{
unsigned char *buf = _buf;
_ARC4_LOCK();
arc4_stir_if_needed();
while (n--) {
if (--arc4_count <= 0)
arc4_stir();
buf[n] = arc4_getbyte();
}
_ARC4_UNLOCK();
}
#endif
#endif
I can now with certainty say that this fixes build (and browser runs fine). I don't know what went wrong previously.
If Moonchild doesnt have any objections I will add patch for this for AUR palemoon-gtk3 so people can build with up to date system.
athenian200 wrote: ↑2022-08-03, 03:52
The only reason I'm not testing this now is because there aren't any Linux distros I have experience with shipping glibc 2.36 and it would be easier to wait for a beta version of Fedora 37 if I have to do the work myself.
No experience with Arch? It includes installer since couple months, just run command `archinstall` in live iso. For desktop users distro doesn't really matter and I guess it won't be really different for compiling.
Re: Building fails with glibc 2.36
Posted: 2022-08-13, 03:29
by 0strodamus
FWIW, I tried building with athenian200's Solution 2 and had the following build error:
Code: Select all
/platform/ipc/chromium/src/third_party/libevent/./arc4random.c:490:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration
Building with Solution 1 worked as others have noted.
Re: Building fails with glibc 2.36
Posted: 2022-08-13, 04:17
by athenian200
0strodamus wrote: ↑2022-08-13, 03:29
FWIW, I tried building with athenian200's Solution 2 and had the following build error:
Code: Select all
/platform/ipc/chromium/src/third_party/libevent/./arc4random.c:490:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration
Building with Solution 1 worked as others have noted.
Yeah, I only provided the second solution as a backup plan, since I didn't have a machine with new glibc in front of me. I expected the first one to work because it's exactly what I did for Solaris. It means my assessment of the problem was correct, and the situation that would have required the second solution didn't materialize.