GNU/Hurd support

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

Moderators: trava90, athenian200

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

GNU/Hurd support

Unread post by jobbautista9 » 2022-09-03, 03:44

As a fun experiment I tried porting UXP to GNU/Hurd, and it wasn't surprisingly as hurd hard as I think. I already have a good place to start with the porting at bug #1029809, which ported Firefox 45 to Hurd. It wasn't enough though, and I've expected that since the code differences between 45 and our codebase are pretty big. As you can see at https://repo.palemoon.org/jobbautista9/ ... branch/gnu, I had to do other things like disabling a pthread function Hurd doesn't have.

Unfortunately all of that seems to be in vain, as Python for some reason crashes while linking libxul.so, with the following cryptic error:

Code: Select all

sem_wait: Invalid argument
Then after that it's sometimes follows up with two "Fatal Python Errors" where ceval and PyEval_SaveThread are complaining about "tstate mix-up" and "NULL tstate" respectively. Then sometimes it's an error in Hurd's disk_pager.c, for whatever reason. I have no idea why these errors are occurring. I thought it was due to memory exhaustion, but it doesn't seem to be the case as htop tells me I'm only using about 2.45G/3.00G of RAM. And since I know the Hurd is only available in i386 and will be memory constrained, I've borrowed the linker options used by stevepusser for his Debian builds to limit memory usage. I also still have plenty of free disk space, so that can't be the issue either. Maybe the Hurd is just too far behind to be able to properly support Pale Moon, who knows. Which is a shame, because AFAIK the Hurd doesn't have a properly working, up-to-date graphical web browser right now, and the Hurd developers would probably appreciate having Pale Moon work in their OS...

Anyway, fun fact: I found Issue #1995 (UXP) when I was building on Debian GNU/Hurd with the current (i.e. sid) default toolchain, which just so happens to use GCC 12. I had to test on Linux just to make sure it's not my fault. :P
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)

Touhou avatar by ならきゃっと.

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

Re: FreeBSD support

Unread post by Moonchild » 2022-09-03, 09:20

jobbautista9 wrote:
2022-09-03, 03:44
Then after that it's sometimes follows up with two "Fatal Python Errors" where ceval and PyEval_SaveThread are complaining about "tstate mix-up" and "NULL tstate" respectively. Then sometimes it's an error in Hurd's disk_pager.c, for whatever reason. I have no idea why these errors are occurring. I thought it was due to memory exhaustion, but it doesn't seem to be the case as htop tells me I'm only using about 2.45G/3.00G of RAM.
That does sound like memory exhaustion and the issues one would find when the system starts to swap out memory that is actively used for linking. Just because not all RAM is used doesn't mean it's not paging out parts of it as Hurd may reserve some memory for system tasks -- and I also don't know if Hurd has enough address space to go around for linking (why is python involved in linking? aren't you using the gcc linker?) something as large as libxul.
"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: 575
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: FreeBSD support

Unread post by jobbautista9 » 2022-09-03, 09:38

Moonchild wrote:
2022-09-03, 09:20
why is python involved in linking? aren't you using the gcc linker?
I am using GCC's linker indeed, but for some reason it is Python that is crashing, not ld (where the most of the RAM would come from), which is strange to me. I've attached some screenshots below showing the problem I'm facing.

This also means that the linker continues linking libxul on its own, but because there will be no more console output (due to python crashing) and linking libxul.so will take a very long time, the build job (which is the linker) will eventually be SIGKILL'd (learned that when I attached gdb to the linker process and looked at https://xref.palemoon.org/goanna-centra ... link.py#10), preventing me from progressing further...
Hurd's tty
Hurd's tty
Building Pale Moon in a ssh session inside the Hurd
Building Pale Moon in a ssh session inside the Hurd
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)

Touhou avatar by ならきゃっと.

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

Re: GNU/Hurd support

Unread post by Moonchild » 2022-09-04, 09:10

Right, so what's likely happening is that python gets pushed out of memory by the linker taking up all space, crashes, leaves the linking process hanging with no parent process which then gets terminated by the OS.
Also, the "still linking" message should not pop up every minute, but only after like 20.
"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: 575
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: GNU/Hurd support

Unread post by jobbautista9 » 2022-09-04, 12:17

Sorry for the late reply, I was about to create a new thread as you suggested earlier and I got sidetracked by the fact that I once got lucky that the linker actually managed to link almost whole of libxul.so, only to fail because I forgot to disable another pthread_setname_np and didn't tell the compiler that Hurd doesn't have epoll...
Screenshot_2022-09-03_19-02-09.png
Seeing this success, I naively tried to link libxul again and again after fixing the linker's complaints, and luck didn't give me the chance this time. I wasted hours on that one...
Moonchild wrote:
2022-09-04, 09:10
Also, the "still linking" message should not pop up every minute, but only after like 20.
I was tinkering with config/link.py that time, thinking that maybe I could avoid getting the linker killed (and thus saving libxul.so) if I sent out enough console outputs. The plan obviously didn't work, and even if it did I would've run into the earlier epoll and pthread_setname_np issues anyway.
Moonchild wrote:
2022-09-04, 09:10
Right, so what's likely happening is that python gets pushed out of memory by the linker taking up all space, crashes, leaves the linking process hanging with no parent process which then gets terminated by the OS.
That seems to be the likely explanation then. If that's the case then I have no choice but to set up a cross-compilation environment with Linux as the host. I already got gcc, libgcc, and libstdc++ built targeting the Hurd, I just now have to figure out how to cross-compile Pale Moon. According to Firefox's source docs, I just have to put something like "ac_add_options --target=i686-gnu" to my mozconfig. I also have to make sure CC and CXX points to the correct compilers, which would be i686-gnu-gcc and i686-gnu-g++ respectively. That's enough to make the configure script recognize that I'm cross-compiling.

Then I ran into a peculiar error:

Code: Select all

 0:04.52 checking for c++... (cached) /usr/local/bin/i686-gnu-g++ -std=gnu++11
 0:04.66 checking whether the C++ compiler (/usr/local/bin/i686-gnu-g++ -std=gnu++11  ) works... no
 0:04.66 configure: error: installation or configuration problem: C++ compiler cannot create executables.
 0:04.67 DEBUG: <truncated - see config.log for full output>
 0:04.67 DEBUG: configure:1432: /usr/local/bin/i686-gnu-g++ -std=gnu++11 -o conftest    conftest.C  1>&5
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_rwlock_unlock'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_create'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_key_create'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_getspecific'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_key_delete'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_rwlock_rdlock'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_once'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_rwlock_wrlock'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_join'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_setspecific'
 0:04.67 DEBUG: /usr/bin/i686-gnu-ld: /usr/local/lib/gcc/i686-gnu/12.2.0/../../../../i686-gnu/lib/libstdc++.so: undefined reference to `pthread_detach'
 0:04.67 DEBUG: collect2: error: ld returned 1 exit status
 0:04.67 DEBUG: configure: failed program was:
 0:04.67 DEBUG:
 0:04.67 DEBUG: #line 1427 "configure"
 0:04.67 DEBUG: #include "confdefs.h"
 0:04.67 DEBUG:
 0:04.67 DEBUG: int main(){return(0);}
 0:04.67 DEBUG: configure: error: installation or configuration problem: C++ compiler cannot create executables.
 0:04.67 ERROR: old-configure failed
For whatever reason it is not including the pthread library, even though I have --with-pthreads in my mozconfig. In the end I decided to just give up looking at why old-configure is not including pthread libs and instead exported LDFLAGS with "-pthread". That seems to work and I'm now able to truly start compiling.

I will report back whether I succeeded or get stuck. Right now my compiler is complaining about missing <netinet/in.h>, which should be simple to fix (I've forgotten to copy that from my Hurd box).

My current mozconfig:

Code: Select all

export CC=i686-gnu-gcc
export CXX=i686-gnu-g++
export LDFLAGS="-pthread"
mk_add_options PYTHON=/usr/bin/python2
mk_add_options AUTOCONF=/usr/bin/autoconf-2.13

# Set GTK Version to 2 or 3
_GTK_VERSION=3

# Standard build options for Pale Moon
ac_add_options --enable-application=palemoon
ac_add_options --target=i686-gnu
ac_add_options --enable-optimize="-O2 -Wl,--no-keep-memory,--reduce-memory-overhead"
ac_add_options --enable-default-toolkit=cairo-gtk$_GTK_VERSION
ac_add_options --enable-phoenix-extensions
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --enable-av1
ac_add_options --enable-sndio
ac_add_options --enable-pulseaudio
ac_add_options --disable-alsa
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --disable-crashreporter
ac_add_options --disable-accessibility
ac_add_options --disable-parental-controls
ac_add_options --disable-eme
ac_add_options --disable-webrtc
ac_add_options --with-pthreads

# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MC_OFFICIAL=1
export MOZILLA_OFFICIAL=1

ac_add_options --x-libraries=/usr/lib64

export MOZ_PKG_SPECIAL=gtk$_GTK_VERSION
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)

Touhou avatar by ならきゃっと.

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

Re: GNU/Hurd support

Unread post by jobbautista9 » 2022-09-04, 13:58

Well looks like I'm stuck.

Code: Select all

 3:05.23 In file included from /usr/local/include/i386-gnu/errno.h:28,
 3:05.23                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/system_wrappers/errno.h:3,
 3:05.23                  from /usr/local/include/i386-gnu/c++/12.2.0/cerrno:42,
 3:05.23                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/system_wrappers/cerrno:3,
 3:05.23                  from /usr/local/include/i386-gnu/c++/12.2.0/ext/string_conversions.h:44,
 3:05.23                  from /usr/local/include/i386-gnu/c++/12.2.0/bits/basic_string.h:3960,
 3:05.23                  from /usr/local/include/i386-gnu/c++/12.2.0/string:53,
 3:05.23                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/system_wrappers/string:3,
 3:05.23                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/stl_wrappers/string:50,
 3:05.24                  from /usr/local/include/i386-gnu/c++/12.2.0/bits/locale_classes.h:40,
 3:05.24                  from /usr/local/include/i386-gnu/c++/12.2.0/bits/ios_base.h:41,
 3:05.24                  from /usr/local/include/i386-gnu/c++/12.2.0/streambuf:41,
 3:05.24                  from /usr/local/include/i386-gnu/c++/12.2.0/bits/streambuf_iterator.h:35,
 3:05.24                  from /usr/local/include/i386-gnu/c++/12.2.0/iterator:66,
 3:05.24                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/system_wrappers/iterator:3,
 3:05.24                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/stl_wrappers/iterator:50,
 3:05.24                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/include/mozilla/Span.h:35,
 3:05.25                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/include/nsTArray.h:22,
 3:05.25                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/include/nsILoadInfo.h:32,
 3:05.25                  from /home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/include/nsIChannel.h:14,
 3:05.25                  from /home/job/Software/uxp-work/platform/image/decoders/icon/gtk/nsIconChannel.h:10,
 3:05.25                  from /home/job/Software/uxp-work/platform/image/decoders/icon/gtk/nsIconChannel.cpp:6:
 3:05.25 /usr/include/x86_64-linux-gnu/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory
 3:05.25    26 | # include <linux/errno.h>
 3:05.25       |           ^~~~~~~~~~~~~~~
 3:05.25 compilation terminated.
 3:05.25 
 3:05.25 In the directory  /home/job/Software/uxp-work/palemoon/obj-i686-gnu/image/decoders/icon/gtk
 3:05.26 The following command failed to execute properly:
 3:05.26 /usr/local/bin/i686-gnu-g++ -std=gnu++11 -o nsIconChannel.o -c -I/home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/stl_wrappers -I/home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/system_wrappers -include /home/job/Software/uxp-work/platform/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/home/job/Software/uxp-work/platform/image/decoders/icon/gtk -I/home/job/Software/uxp-work/palemoon/obj-i686-gnu/image/decoders/icon/gtk -I/home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/include -I/home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/include/nspr -I/home/job/Software/uxp-work/palemoon/obj-i686-gnu/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /home/job/Software/uxp-work/palemoon/obj-i686-gnu/mozilla-config.h -MD -MP -MF .deps/nsIconChannel.o.pp -DPATH_MAX=1024 -DMAXPATHLEN=1024 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=multistatement-macros -flifetime-dse=1 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pipe -msse2 -mfpmath=sse -pthread -g -O2 -w -Wl,--no-keep-memory,--reduce-memory-overhead -fomit-frame-pointer -I/home/job/Software/uxp-work/platform/widget/gtk/compat-gtk3 -pthread -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/x86_64-linux-gnu -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include /home/job/Software/uxp-work/platform/image/decoders/icon/gtk/nsIconChannel.cpp
 3:05.27 gmake[5]: *** [/home/job/Software/uxp-work/platform/config/rules.mk:886: nsIconChannel.o] Error 1
 3:05.27 gmake[4]: *** [/home/job/Software/uxp-work/platform/config/recurse.mk:71: image/decoders/icon/gtk/target] Error 2
 
For some reason the compiler is including the host system's headers instead of the target's. I tried exporting C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to only include the i686-gnu headers, and modifying my --x-includes and --x-libraries in my mozconfig, but same error results. I'm back in the "I have no idea why this error is happening" stage...

Current mozconfig:

Code: Select all

export CC=i686-gnu-gcc
export CXX=i686-gnu-g++
export LDFLAGS=-pthread
export C_INCLUDE_PATH=/usr/i686-gnu/include
export CPLUS_INCLUDE_PATH=/usr/i686-gnu/include
export OBJC_INCLUDE_PATH=/usr/i686-gnu/include
mk_add_options PYTHON=/usr/bin/python2
mk_add_options AUTOCONF=/usr/bin/autoconf-2.13

# Set GTK Version to 2 or 3
_GTK_VERSION=3

# Standard build options for Pale Moon
ac_add_options --enable-application=palemoon
ac_add_options --target=i686-gnu
ac_add_options --enable-optimize="-O2 -w -Wl,--no-keep-memory,--reduce-memory-overhead"
ac_add_options --enable-default-toolkit=cairo-gtk$_GTK_VERSION
ac_add_options --enable-phoenix-extensions
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --enable-av1
ac_add_options --enable-sndio
ac_add_options --enable-pulseaudio
ac_add_options --disable-alsa
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --disable-crashreporter
ac_add_options --disable-accessibility
ac_add_options --disable-parental-controls
ac_add_options --disable-eme
ac_add_options --disable-webrtc
ac_add_options --with-pthreads

# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MC_OFFICIAL=1
export MOZILLA_OFFICIAL=1

ac_add_options --x-includes=/usr/i686-gnu/include
ac_add_options --x-libraries=/usr/i686-gnu/lib

export MOZ_PKG_SPECIAL=gtk$_GTK_VERSION
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)

Touhou avatar by ならきゃっと.

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

Re: GNU/Hurd support

Unread post by Moonchild » 2022-09-04, 14:00

You may have to add --host= as well as --target= to indicate it's cross-compiling?
I never had much luck cross-compiling Mozilla code bases myself aside from Android stuff (and even that was a bit of a pain). Sorry I'm not much of a help here.
"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: 575
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: GNU/Hurd support

Unread post by jobbautista9 » 2022-09-04, 14:16

I already added --target=i686-gnu as that's required. --host=i686-gnu though... I tried that, but it then errors out earlier than without:

Code: Select all

 0:39.63 mozilla-config.h
 0:39.79 buildid.h
 0:39.96 source-repo.h
 0:40.48 nsinstall_real
 0:40.65 gmake[5]: ../config/nsinstall: No such file or directory
 0:40.65 gmake[5]: *** [/home/job/Software/uxp-work/platform/config/rules.mk:1295: ../dist/bin/nsinstall] Error 127
 0:40.65 gmake[4]: *** [/home/job/Software/uxp-work/platform/config/recurse.mk:71: config/host] Error 2
 0:40.65 gmake[3]: *** [/home/job/Software/uxp-work/platform/config/recurse.mk:33: export] Error 2
 0:40.65 gmake[2]: *** [/home/job/Software/uxp-work/platform/config/rules.mk:494: default] Error 2
 0:40.65 gmake[1]: *** [/home/job/Software/uxp-work/palemoon/client.mk:406: realbuild] Error 2
 0:40.65 gmake: *** [client.mk:164: build] Error 2
 
And even if it succeeded there somehow, I will probably run into other sorts of issues because the build system will assume I'm not cross-compiling.

If you're saying --host=x86_64-linux-gnu, then it is redundant because old-configure can auto-detect what my host system is anyway. So only --target is required for cross-compiling.
Moonchild wrote:
2022-09-04, 14:00
Sorry I'm not much of a help here.
No worries! Cross-compilation is definitely tricky stuff, and I can't blame you there. I guess I will just call it quits right here for now and consider Hurd unviable for the moment. Maybe if the Hurd developers finally add proper x86_64 support, or someone more experienced can give me some pointers on how to make the build system only include i686-gnu system headers, I would go back in working on this...
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)

Touhou avatar by ならきゃっと.

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

Re: GNU/Hurd support

Unread post by Moonchild » 2022-09-04, 15:34

no, I mean setting your host to your actual host system (not hurd) :) explicitly indicating to the build system you are cross-compiling that way.
"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: 575
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: GNU/Hurd support

Unread post by jobbautista9 » 2022-09-05, 07:25

I found the culprit: it seems that the build system is using my host's pkg-config since it can't find the one for i686-gnu, which explains why it was using my host system's includes. For now I've hacked old-configure directly so that variables like MOZ_GTK2_CFLAGS will be hardcoded to the target system's includes instead of using pkg-config. I will figure out a better solution later...

That means I'm now able to finally build Pale Moon completely! It also runs fine too, if you don't mind the snail-like speed of a VM and remote X11... But what's important is that we have a working Pale Moon now in GNU/Hurd!! :D
Screenshot_2022-09-05_15-09-16.png
Screenshot_2022-09-05_15-09-57.png
Screenshot_2022-09-05_15-23-47.png
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)

Touhou avatar by ならきゃっと.

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

Re: GNU/Hurd support

Unread post by Moonchild » 2022-09-05, 08:38

Huzzah! :thumbup:
"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
athenian200
Contributing developer
Contributing developer
Posts: 892
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: GNU/Hurd support

Unread post by athenian200 » 2022-09-05, 16:39

jobbautista9 wrote:
2022-09-05, 07:25
I found the culprit: it seems that the build system is using my host's pkg-config since it can't find the one for i686-gnu, which explains why it was using my host system's includes. For now I've hacked old-configure directly so that variables like MOZ_GTK2_CFLAGS will be hardcoded to the target system's includes instead of using pkg-config. I will figure out a better solution later...

That means I'm now able to finally build Pale Moon completely! It also runs fine too, if you don't mind the snail-like speed of a VM and remote X11... But what's important is that we have a working Pale Moon now in GNU/Hurd!! :D
I'm glad you figured it out. I was about to suggest pkg-config because I've gotten weird issues due to packages randomly trying to use the 32-bit version of it when I want 64-bit, and it results in the same kind of issues. I can usually get around it using PKG_CONFIG_PATH set to the path I want. EDIT: Look at this 64-bit mozconfig for reference (noting that it is way out of date), this was needed when I initially did my SunOS port because our copy of config.guess was defaulting to 32-bit builds.

The main reason I chose to support illumos and Solaris rather than GNU Hurd or Minix is because of the fact that Hurd and Minix are still 32-bit only. 32-bit operating systems are barely sufficient for browsing anymore (let alone compiling), IMO. 4GB of RAM is a tight fit.
"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
jobbautista9
Astronaut
Astronaut
Posts: 575
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: GNU/Hurd support

Unread post by jobbautista9 » 2022-09-06, 01:54

athenian200 wrote:
2022-09-05, 16:39
I can usually get around it using PKG_CONFIG_PATH set to the path I want.
I exported PKG_CONFIG in my mozconfig to point to /usr/bin/i686-gnu-pkg-config instead, and it works too. I'm not sure about PKG_CONFIG_PATH though, since both the "pkg-config" (which points to my host system's pkg-config) and "i686-gnu-pkg-config" are in the same /usr/bin directory. But I got it working now without having to hack old-configure. I wanted to touch as little of the source code as possible.
athenian200 wrote:
2022-09-05, 16:39
The main reason I chose to support illumos and Solaris rather than GNU Hurd or Minix is because of the fact that Hurd and Minix are still 32-bit only. 32-bit operating systems are barely sufficient for browsing anymore (let alone compiling), IMO. 4GB of RAM is a tight fit.
Yeah, 32-bit only is a bummer. However the Hurd is still in development despite its releases being dead. Their git repos still shows some recent commits, and the Debian distribution of the Hurd is still alive. Minix meanwhile seems to be dead, and uses a package management system I'm not familiar with (which would be NetBSD pkgsrc). In Debian GNU/Hurd I can use apt as I always do in Devuan, which made the porting easier for me.

Anyway, here's my mozconfig for cross-compiling from a Linux host:

Code: Select all

# Configure doesn't detect our Hurd-targeted pkg-config for some reason, even
# with --target explicitly defined as GNU.
export PKG_CONFIG=/usr/bin/i686-gnu-pkg-config

# Needed because for some reason even with --with-pthreads, -pthread is not
# being added to the LDFLAGS, resulting in error with the C++ compiler test
export LDFLAGS=-pthread

# Python 3 is not supported.
mk_add_options PYTHON=/usr/bin/python2

# Build system needs exactly version 2.13 for autoconf.
mk_add_options AUTOCONF=/usr/bin/autoconf-2.13

# Set GTK Version to 2 or 3
_GTK_VERSION=3

# Cross-compile to GNU/Hurd
ac_add_options --target=i686-gnu

# Local sound support in GNU/Hurd is not good, but networked audio should work
# fine, so let's give users the choice of using either PulseAudio or sndio for
# networked audio. If both sound servers are installed, PulseAudio will be used.
ac_add_options --enable-sndio
ac_add_options --enable-pulseaudio
ac_add_options --disable-alsa

# Standard build options for Pale Moon
ac_add_options --enable-application=palemoon
ac_add_options --enable-optimize="-O2 -w"
ac_add_options --enable-default-toolkit=cairo-gtk$_GTK_VERSION
ac_add_options --enable-phoenix-extensions
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --enable-av1
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --disable-crashreporter
ac_add_options --disable-accessibility
ac_add_options --disable-parental-controls
ac_add_options --disable-eme
ac_add_options --disable-webrtc
ac_add_options --with-pthreads

# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --disable-official-branding

ac_add_options --x-includes=/usr/i686-gnu/include
ac_add_options --x-libraries=/usr/i686-gnu/lib

export MOZ_PKG_SPECIAL=gtk$_GTK_VERSION
For native compilation, it should be mostly the same as the build instructions for Linux. I don't recommend trying it until the Hurd supports x86_64 (which is still in progress).

Btw, can I share my build to other people? It will be unbranded of course (hopefully the mozconfig I've pasted above is enough to make it unbranded). I want to have people running the Hurd in bare metal to try it and see what they think. I'm also going to try cross-compiling Basilisk and Hermopolis for the Hurd before I start working on a pull request, if you will accept it. Maintenance shouldn't be too hard as the Hurd is closer to GNU/Linux; it just has an inferior pthreads implementation and some other few stuff missing (like epoll). And I'd like to try making a GNU/Hurd desktop that I can use everyday (even it means just basic stuff like office work and very light web browsing), so I will be available in keeping the platform buildable and runnable in the Hurd. :)
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)

Touhou avatar by ならきゃっと.

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

Re: GNU/Hurd support

Unread post by Moonchild » 2022-09-06, 06:24

jobbautista9 wrote:
2022-09-06, 01:54
Btw, can I share my build to other people? It will be unbranded of course (hopefully the mozconfig I've pasted above is enough to make it unbranded).
If it's unbranded then you can do whatever you want with it without having to ask :)
And actually, there's no issue using official branding if you're not materially changing or reconfiguring the browser but just making a contributed build on a platform that otherwise doesn't have compatible binaries for it. I allow for that specifically in the redist license. See point 12 (and 8). If GNU is going to be GNU and saying "it's not Linux!" then you get my permission here to treat GNU/Hurd the same as Linux operating systems. I'll adjust the text later today to be a bit more broad in that respect.
"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: 575
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: GNU/Hurd support

Unread post by jobbautista9 » 2022-09-06, 07:44

Ah, I see. I haven't gotten my Hurd patches merged to your repo, so I was worried that I might violate your trademarks if I use official branding. Thanks for the clarification! :D
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)

Touhou avatar by ならきゃっと.

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

Re: GNU/Hurd support

Unread post by Moonchild » 2022-09-06, 07:56

It's not dependent on whether it's in the main repo :)
In fact, that would be counter-productive since we cannot accept all patches that might be necessary for left-field O.S. variants that need special snowflake hacks that would break compatibility with bigger distros otherwise, etc.

Just updated the wording, by the way. Nothing material changed but I hope it's a bit clearer now that it covers all UNIX-like operating systems.
"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
athenian200
Contributing developer
Contributing developer
Posts: 892
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: GNU/Hurd support

Unread post by athenian200 » 2022-09-06, 12:05

jobbautista9 wrote:
2022-09-06, 01:54
I exported PKG_CONFIG in my mozconfig to point to /usr/bin/i686-gnu-pkg-config instead, and it works too. I'm not sure about PKG_CONFIG_PATH though, since both the "pkg-config" (which points to my host system's pkg-config) and "i686-gnu-pkg-config" are in the same /usr/bin directory. But I got it working now without having to hack old-configure. I wanted to touch as little of the source code as possible.
Well, that would explain why you didn't think of that option. :) In every situation where I've had to do that, there were two different paths involved. Usually I wouldn't want to just put two pkg-configs into the same path (I didn't even know that was a thing people did?) and just name one something different, but rather I would have it always named pkg-config but available at two different paths.
"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
frostknight
Apollo supporter
Apollo supporter
Posts: 38
Joined: 2022-08-10, 02:25

Re: GNU/Hurd support

Unread post by frostknight » 2022-10-05, 02:28

Moonchild wrote:
2022-09-06, 07:56
It's not dependent on whether it's in the main repo :)
In fact, that would be counter-productive since we cannot accept all patches that might be necessary for left-field O.S. variants that need special snowflake hacks that would break compatibility with bigger distros otherwise, etc.

Just updated the wording, by the way. Nothing material changed but I hope it's a bit clearer now that it covers all UNIX-like operating systems.
To be honest, last I heard of Hurd, it was something that was really not very functional and was only being continued for research type purposes.

I am surprised given this, that someone even could port it to Hurd. I would think the time would be better spent porting it to BSDs Although, that might be extremely hard given the last thing that happened when someone was unaware of the trademark stuff involved.

Either way...

:shock:

Actually am... I was told it had instability issues.

Post Reply