Building fails with glibc 2.36

Discussions about the development and maturation of the platform code (GRE).
Warning: may contain highly-technical topics.

Moderators: trava90, athenian200

User avatar
micwoj92
Fanatic
Fanatic
Posts: 156
Joined: 2020-12-22, 20:57

Building fails with glibc 2.36

Unread post by micwoj92 » 2022-08-02, 05:47

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.

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 850
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Building fails with glibc 2.36

Unread post by athenian200 » 2022-08-02, 10:08

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:

Code: Select all

#undef arc4random_buf 
So that the definition in the headers doesn't interfere.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
micwoj92
Fanatic
Fanatic
Posts: 156
Joined: 2020-12-22, 20:57

Re: Building fails with glibc 2.36

Unread post by micwoj92 » 2022-08-02, 10:18

Arch Linux has it in testing repos, probably will be core in around a week or two.

vannilla
Board Warrior
Board Warrior
Posts: 1973
Joined: 2018-05-05, 13:29

Re: Building fails with glibc 2.36

Unread post by vannilla » 2022-08-02, 11:41

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).

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32674
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Building fails with glibc 2.36

Unread post by Moonchild » 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.

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...
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

User avatar
micwoj92
Fanatic
Fanatic
Posts: 156
Joined: 2020-12-22, 20:57

Re: Building fails with glibc 2.36

Unread post by micwoj92 » 2022-08-02, 22:38

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.

User avatar
andyprough
Lunatic
Lunatic
Posts: 328
Joined: 2020-05-31, 04:33

Re: Building fails with glibc 2.36

Unread post by andyprough » 2022-08-02, 23:31

athenian200 wrote:
2022-08-02, 10:08
you could try conditionally doing something like:

Code: Select all

#undef arc4random_buf 
So that the definition in the headers doesn't interfere.
I'm not following you. Would this be an option in .mozconfig?
Self-compiled Pale Moon on Libre-antiX GNU/Linux respin, 32-bit and 64-bit, and on Hyperbola GNU/Linux 64-bit

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 850
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Building fails with glibc 2.36

Unread post by athenian200 » 2022-08-03, 01:43

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.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
andyprough
Lunatic
Lunatic
Posts: 328
Joined: 2020-05-31, 04:33

Re: Building fails with glibc 2.36

Unread post by andyprough » 2022-08-03, 03:28

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.
Self-compiled Pale Moon on Libre-antiX GNU/Linux respin, 32-bit and 64-bit, and on Hyperbola GNU/Linux 64-bit

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 850
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Building fails with glibc 2.36

Unread post by athenian200 » 2022-08-03, 03:52

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.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
micwoj92
Fanatic
Fanatic
Posts: 156
Joined: 2020-12-22, 20:57

Re: Building fails with glibc 2.36

Unread post by micwoj92 » 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.

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 850
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Building fails with glibc 2.36

Unread post by athenian200 » 2022-08-03, 04:11

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.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32674
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Building fails with glibc 2.36

Unread post by Moonchild » 2022-08-03, 04:44

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.
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

User avatar
jobbautista9
Astronaut
Astronaut
Posts: 534
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Building fails with glibc 2.36

Unread post by jobbautista9 » 2022-08-03, 04:44

@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
smug mima

Developer of Ambassador in Window Menu, BrowserTickTock, CacheSwitch, Chrome Navigator, Cite4Wiki, Clickity Touch 'n Push, ColorPili, EditDatContent, EditDatTitle, Esrever, Go Menu, User Agent Status, Website Navigation Bar, and Yet Another about:config Helper.

My PGP public key (My copy on rw.rs)

I don't know who made this Touhou avatar. I found this in Danbooru.

User avatar
micwoj92
Fanatic
Fanatic
Posts: 156
Joined: 2020-12-22, 20:57

Re: Building fails with glibc 2.36

Unread post by micwoj92 » 2022-08-03, 04:49

jobbautista9 wrote:
2022-08-03, 04:44
@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
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.

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 850
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Building fails with glibc 2.36

Unread post by athenian200 » 2022-08-03, 04:55

jobbautista9 wrote:
2022-08-03, 04:44
@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
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.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
micwoj92
Fanatic
Fanatic
Posts: 156
Joined: 2020-12-22, 20:57

Re: Building fails with glibc 2.36

Unread post by micwoj92 » 2022-08-03, 06:44

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.

0strodamus
Fanatic
Fanatic
Posts: 141
Joined: 2014-11-19, 19:48

Re: Building fails with glibc 2.36

Unread post by 0strodamus » 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.

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 850
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Building fails with glibc 2.36

Unread post by athenian200 » 2022-08-13, 04:17

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.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

Post Reply