Providing of uclibc / musl patches in attendance of pale moon sourcecode change
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!
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!
Providing of uclibc / musl patches in attendance of pale moon sourcecode change
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).
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).
- stevenpusser
- Project Contributor
- Posts: 903
- Joined: 2015-08-01, 18:33
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
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.
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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
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:
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.
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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
I didn't notice that "--with-system-graphite2" configure option exists at first.
Btw, it now fails at some linking process.
Possibly due to some PIC/PIE compiler flag issue.
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
Last edited by terranigma on 2018-03-10, 10:51, edited 1 time in total.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
@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.
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
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.
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
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- 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
Can you try the same setup, but with "-fno-pic -fno-PIC" added to CFLAGS/CXXFLAGS?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.
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
Changing CFLAGS directly is stupid.. Stop recommending it.Walter Dnes wrote:Can you try the same setup, but with "-fno-pic -fno-PIC" added to CFLAGS/CXXFLAGS?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.
Re: Providing of uclibc / musl patches in attendance of pale moon sourcecode change
I was mistaken.. to use system graphite2/harfbuzz, a patch from FreeBSD port is needed:terranigma wrote:I didn't notice that "--with-system-graphite2" configure option exists at first.
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
@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
I meant the following in that link:terranigma wrote: @Peregrine
I already checked those links but couldn't find something useful.
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.