Page 1 of 1
Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-09, 15:17
by Peregrine
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).
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-09, 22:22
by stevenpusser
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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-10, 02:15
by terranigma
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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-10, 10:50
by terranigma
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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-10, 14:42
by Peregrine
@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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-10, 15:04
by Moonchild
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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-10, 16:54
by Walter Dnes
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?
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-10, 17:08
by New Tobin Paradigm
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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-10, 21:28
by terranigma
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
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Posted: 2018-03-12, 16:50
by Peregrine
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.