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

Support and discussions for the x86/x64 Linux version of Pale Moon.

Moderators: trava90, satrow

Peregrine
Hobby Astronomer
Hobby Astronomer
Posts: 28
Joined: Mon, 26 Oct 2015, 08:39
Location: planet earth, orion arm, milky way, the universe

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

Postby Peregrine » Fri, 09 Mar 2018, 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
stevepusser
Lunatic
Lunatic
Posts: 340
Joined: Sat, 01 Aug 2015, 18:33
Location: California

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

Postby stevepusser » Fri, 09 Mar 2018, 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 stevepusser on Fri, 09 Mar 2018, 22:25, edited 1 time in total.

User avatar
terranigma
Hobby Astronomer
Hobby Astronomer
Posts: 19
Joined: Sat, 10 Mar 2018, 01:46

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

Postby terranigma » Sat, 10 Mar 2018, 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 Sat, 10 Mar 2018, 09:50, edited 3 times in total.

User avatar
terranigma
Hobby Astronomer
Hobby Astronomer
Posts: 19
Joined: Sat, 10 Mar 2018, 01:46

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

Postby terranigma » Sat, 10 Mar 2018, 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 Sat, 10 Mar 2018, 10:51, edited 1 time in total.

Peregrine
Hobby Astronomer
Hobby Astronomer
Posts: 28
Joined: Mon, 26 Oct 2015, 08:39
Location: planet earth, orion arm, milky way, the universe

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

Postby Peregrine » Sat, 10 Mar 2018, 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: 21182
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

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

Postby Moonchild » Sat, 10 Mar 2018, 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.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"The wisest men follow their own direction." - Euripedes

Walter Dnes
Astronaut
Astronaut
Posts: 506
Joined: Thu, 30 Jul 2015, 20:29
Location: Vaughan, ON, Canada

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

Postby Walter Dnes » Sat, 10 Mar 2018, 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

User avatar
New Tobin Paradigm
Banned user
Banned user
Posts: 4417
Joined: Tue, 09 Oct 2012, 19:37

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

Postby New Tobin Paradigm » Sat, 10 Mar 2018, 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.
I hate Pod Six. Tch, I don't even know why we have a Pod Six. Total suck Pod.
[ ニュー・トビン・パラダイム ]

User avatar
terranigma
Hobby Astronomer
Hobby Astronomer
Posts: 19
Joined: Sat, 10 Mar 2018, 01:46

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

Postby terranigma » Sat, 10 Mar 2018, 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
Hobby Astronomer
Hobby Astronomer
Posts: 28
Joined: Mon, 26 Oct 2015, 08:39
Location: planet earth, orion arm, milky way, the universe

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

Postby Peregrine » Mon, 12 Mar 2018, 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.


Return to “Pale Moon for Linux”

Who is online

Users browsing this forum: No registered users and 6 guests