Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

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!
Peregrine

Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by Peregrine » 2018-03-09, 15:17

For a while now, uclibc and musl remained unsupported by pale moon, meaning that people that have uclibc or musl (instead of glibc) simply are not able to run pale moon on their machine.

I think this issue might soon be picked up by some developers (which might devise a way to build it on uclibc and musl, possibly by means of a source code change), but in the meantime, people with distro's that have uclibc or musl are still in the cold. Moving to a distro with glibc is an option, but since uclibc and musl are WAY better than glibc, that would mean people would actually need to downgrade their entire system, just to be able to run palemoon (which is after all, just one program -albeit it one of the most important ones on the system-).

So, I was thinking: could, for the meantime, uclibc and musl patches be made available on the website for the binary palemoon version (http://linux.palemoon.org/download/mainline/ ) ? The binary palemoon version is build with glibc so mere patches could allow this version to become suitable for either uclibc or musl. Also, since the binary version is linux-wide (all linux distro's), these patches could increase the user pool considerably (since there are quite a few uclibc and musl distro's out there).

User avatar
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by stevenpusser » 2018-03-09, 22:22

Do these patches exist anywhere? Do they live out there in thoughtspace with the clang patches?

And I'm arm-waving here, but I think a better solution would be for the build system to detect what compiler is in use and adapt appropriately.
Last edited by stevenpusser on 2018-03-09, 22:25, edited 1 time in total.

terranigma

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by terranigma » 2018-03-10, 02:15

I'm the one of those who try to compile PM with musl-libc/clang-5 toolchain on Alpine Linux. Unfortunately, status is not promising yet. I'm trying to depend on system libraries as much as possible to get a shortcut. This seems a good strategy until getting an error due to glibc specific definitions or compiler incompatiblities.

Now I'm stuck on this:

Code: Select all

 0:10.81 Unified_cpp_dom_media_platforms0.o
 0:10.92 In file included from /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/obj-x86_64-unknown-linux-gnu/gfx/graphite2/src/Unified_cpp_gfx_graphite2_src0.cpp:119:
 0:10.92 In file included from /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/NameTable.cpp:31:
 0:10.92 /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/inc/UtfCodec.h:216:46: error: invalid operands to binary expression ('const unsigned short *' and 'typename __gnu_cxx::__enable_if<__is_integer<signed char>::__value, double>::__type' (aka 'double'))
 0:10.92     _utf_iterator   & operator ++ ()    { cp += abs(sl); return *this; }
 0:10.92                                           ~~ ^  ~~~~~~~
 0:10.92 /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/NameTable.cpp:181:88: note: in instantiation of member function 'graphite2::_utf_iterator<const unsigned short>::operator++' requested here
 0:10.92         for (utf16::const_iterator s = utf16Name, e = utf16Name + utf16Length; s != e; ++s, ++d)
 0:10.92                                                                                        ^
 0:10.92 In file included from /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/obj-x86_64-unknown-linux-gnu/gfx/graphite2/src/Unified_cpp_gfx_graphite2_src0.cpp:119:
 0:10.92 In file included from /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/NameTable.cpp:31:
 0:10.92 /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/inc/UtfCodec.h:216:46: error: invalid operands to binary expression ('unsigned char *' and 'typename __gnu_cxx::__enable_if<__is_integer<signed char>::__value, double>::__type' (aka 'double'))
 0:10.92     _utf_iterator   & operator ++ ()    { cp += abs(sl); return *this; }
 0:10.92                                           ~~ ^  ~~~~~~~
 0:10.92 /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/NameTable.cpp:181:93: note: in instantiation of member function 'graphite2::_utf_iterator<unsigned char>::operator++' requested here
 0:10.92         for (utf16::const_iterator s = utf16Name, e = utf16Name + utf16Length; s != e; ++s, ++d)
 0:10.92                                                                                             ^
 0:10.92 In file included from /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/obj-x86_64-unknown-linux-gnu/gfx/graphite2/src/Unified_cpp_gfx_graphite2_src0.cpp:119:
 0:10.92 In file included from /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/NameTable.cpp:31:
 0:10.92 /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/inc/UtfCodec.h:216:46: error: invalid operands to binary expression ('unsigned int *' and 'typename __gnu_cxx::__enable_if<__is_integer<signed char>::__value, double>::__type' (aka 'double'))
 0:10.92     _utf_iterator   & operator ++ ()    { cp += abs(sl); return *this; }
 0:10.92                                           ~~ ^  ~~~~~~~
 0:10.93 /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/gfx/graphite2/src/NameTable.cpp:202:93: note: in instantiation of member function 'graphite2::_utf_iterator<unsigned int>::operator++' requested here
 0:10.93         for (utf16::const_iterator s = utf16Name, e = utf16Name + utf16Length; s != e; ++s, ++d)
 0:10.93                                                                                             ^
 0:10.93 3 errors generated.
 0:10.93 In the directory  /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/obj-x86_64-unknown-linux-gnu/gfx/graphite2/src


Same code above (standalone graphite2 package) can be compiled in same environment.. but in PM source tree, things get different.

Even If I figure this out, I have no guarantee for another issue won't be on the way.
Last edited by terranigma on 2018-03-10, 09:50, edited 3 times in total.

terranigma

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by terranigma » 2018-03-10, 10:50

I didn't notice that "--with-system-graphite2" configure option exists at first.

Btw, it now fails at some linking process.

Code: Select all

 6:40.12 Unified_cpp_js_src0.o: In function `js::AsmJSModule::staticallyLink(js::ExclusiveContext*)':
 6:40.12 /home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/obj-x86_64-unknown-linux-gnu/js/src/Unified_cpp_js_src0.cpp:(.text+0x685f): undefined reference to `log'
 6:40.12 /usr/bin/ld: Unified_cpp_js_src0.o: relocation R_X86_64_PC32 against undefined hidden symbol `log' can not be used when making a shared object
 6:40.12 /usr/bin/ld: final link failed: Bad value
 6:40.12 clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
 6:40.12 make[5]: *** [/home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/config/rules.mk:820: libmozjs.so] Error 1
 6:40.12 make[4]: *** [/home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/config/recurse.mk:74: js/src/target] Error 2
 6:40.12 make[3]: *** [/home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/config/recurse.mk:37: compile] Error 2
 6:40.13 make[2]: *** [/home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/config/rules.mk:541: default] Error 2
 6:40.13 make[1]: *** [/home/apk/aports/testing/palemoon/src/Pale-Moon-27.8.1_Release/client.mk:399: realbuild] Error 2
 6:40.13 make: *** [client.mk:171: build] Error 2
 6:40.16 130 compiler warnings present.
 6:40.18 Notification center failed: Install the python dbus module to get a notification when the build finishes.
>>> ERROR: palemoon: build faile
Possibly due to some PIC/PIE compiler flag issue.
Last edited by terranigma on 2018-03-10, 10:51, edited 1 time in total.

Peregrine

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by Peregrine » 2018-03-10, 14:42

@stevepusser
Yes, the patches live out in thoughtspace for the time being.
Hopefully, someone from the palemoon community will make them.

As for the better solution that would be for the build system to detect what compiler is in use and adapt appropriately:
indeed I thought of this too, see https://github.com/Bfgeshka/octopus/issues/10
As mentioned in this post however, I think people are already working on this, but it will take more time. A fast temporary solution is to create patches for the binary palemoon version, so we don't need to wait ages for the improved source code that allows easy building of palemoon.

@terranigma
See https://github.com/Bfgeshka/octopus/issues/10 , you should be able to find a whole range of links there that could be of use, since others have tried to build it already on musl.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by Moonchild » 2018-03-10, 15:04

Patching compiled binaries to force compatibility with a different run-time library is risky at best, and disastrous at worst. Something with the complexity and size of the Mozilla code base cannot simply be hacked into working properly on a different run-time library that is API-incompatible.

If you want to help, then help with the effort to get source patches in to allow building against musl/uclibc.
Of note too: if you want to provide experimental patched binaries in the meantime, you are not allowed to use officially-branded ones and should indicate the experimental nature of them.
"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

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by Walter Dnes » 2018-03-10, 16:54

terranigma wrote:I didn't notice that "--with-system-graphite2" configure option exists at first.

Btw, it now fails at some linking process.

[...deletia...]

Possibly due to some PIC/PIE compiler flag issue.
Can you try the same setup, but with "-fno-pic -fno-PIC" added to CFLAGS/CXXFLAGS?
There's a right way
There's a wrong way
And then there's my way

New Tobin Paradigm

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by New Tobin Paradigm » 2018-03-10, 17:08

Walter Dnes wrote:
terranigma wrote:I didn't notice that "--with-system-graphite2" configure option exists at first.

Btw, it now fails at some linking process.

[...deletia...]

Possibly due to some PIC/PIE compiler flag issue.
Can you try the same setup, but with "-fno-pic -fno-PIC" added to CFLAGS/CXXFLAGS?
Changing CFLAGS directly is stupid.. Stop recommending it.

terranigma

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by terranigma » 2018-03-10, 21:28

terranigma wrote:I didn't notice that "--with-system-graphite2" configure option exists at first.
I was mistaken.. to use system graphite2/harfbuzz, a patch from FreeBSD port is needed:
https://svnweb.freebsd.org/ports/head/w ... 38&view=co

Btw, that linking error still remains. That seems a toolchain (clang-5 in my case) incompatibility issue. Gcc-6.4 fails straight at start.

Code: Select all

 0:42.05 ../../../dist/system_wrappers/features.h:2:9: error: '#pragma' is not allowed here
 0:42.05  #pragma GCC visibility push(default)
 0:42.05          ^~~
 0:42.05 ../../../dist/system_wrappers/features.h:4:27: error: expected declaration before end of line
 0:42.05  #pragma GCC visibility pop
Musl-Glibc issues tend to be trapped easily and generally solved by following early practices.

@Peregrine
I already checked those links but couldn't find something useful.

@Walter Dnes
Fails right at the start

Peregrine

Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change

Unread post by Peregrine » 2018-03-12, 16:50

terranigma wrote: @Peregrine
I already checked those links but couldn't find something useful.
I meant the following in that link:

viewtopic.php?f=61&t=18176
the issues mentioned in that last URL can be resolved by replacing "caddr_t" everywhere by "void *" in the code base.

Locked