I added three patches from Alpine Linux and had to cheat around the app-text/liblangtag dependency by adding --diable-liblang and deleting it from COMMON_DEPEND in the ebuild. so please test.
Created attachment 401440 [details, diff] patch against hardened-development overlay
Thanks for the patch! Please delete the Changelogs from the patch. liblangtag does not build with musl?
https://bitbucket.org/tagoh/liblangtag/issue/12/build-failure-on-linux-with-musl-libc
Created attachment 401748 [details, diff] Upstream patch for liblangtag
Created attachment 401750 [details, diff] Patch for liblangtag against hardened-development overlay @tt_1: Please test the ebuild and see whether you can now emerge libreoffice without disabling liblangtag.
Created attachment 401774 [details, diff] new patch against hardened-development overlay
Created attachment 401778 [details, diff] new patch against hardened-development overlay made a little misstake with the patch, should be ok now. the patch from liblangtag helps to compile, I will test if libreoffice builds with --enabled-liblangtag.
discussion for liblangtag has moved to bug https://bugs.gentoo.org/show_bug.cgi?id=547368
Please provide a diff of your ebuild against the version in the main gentoo tree. The current patch you have attached makes it impossible to see what you changed.
The big patch adds these three patches to the ebuild: http://git.alpinelinux.org/cgit/aports/tree/main/libreoffice/fix-execinfo.patch http://git.alpinelinux.org/cgit/aports/tree/main/libreoffice/fix-includes.patch http://git.alpinelinux.org/cgit/aports/tree/main/libreoffice/linux-musl.patch @tt_1: The patch still removes the liblangtag DEPEND. Also it gives me whitespace errors.
(In reply to tt_1 from comment #7) > Created attachment 401778 [details, diff] [details, diff] > new patch against hardened-development overlay > (In reply to Mike Gilbert from comment #9) > Please provide a diff of your ebuild against the version in the main gentoo > tree. > > The current patch you have attached makes it impossible to see what you > changed. @floppym. They've been making my life easy by creating these full commits against the hardened-development overlay. I don't want to discourage them from doing that, but if they expect a patch to get into the tree, then they need to just produce a diff. Some of the fixes for musl are not ready for the main tree.
Created attachment 401982 [details, diff] patch against hardened-development overlay sry, forgot to add the liblang depend after having deleted it. @ Felix: could you please be a bit more specific concerning these whitespace errors? where are they to be found? diff from in tree libreoffice-4.4.1.2.ebuild to the one in the overlay. the patches are from Alpine. 255a256,258 > "${FILESDIR}/${PN}-4.4.1.2-musl-fix-execinfo.patch" > "${FILESDIR}/${PN}-4.4.1.2-fix-includes.patch" > "${FILESDIR}/${PN}-4.4.1.2-linux-musl.patch"
app-office/libreoffice $ `repoman full` ...is usually quite informative about those kind of things. ;)
Patch looks fine. (I misinterpreted the white space warnings that git apply produces.)
(In reply to tt_1 from comment #12) > Created attachment 401982 [details, diff] [details, diff] > patch against hardened-development overlay Committed against the hardened-dev::musl overlay. Are thse patches going upstream? If not then close this bug.
the three patches from Alpine mentioned in #10 are still aplicable in the up to date 4.4.4.x branch, but a few dependencies do not build properly. such as libcmis:0.5 (see #559518), or >libetonyek-0.1.1 (see #559516).
Created attachment 410970 [details, diff] patch against the musl overlay so, here you go, patches against the musl overlay. for your information stable in-tree of cmake does not build on musl. workaround is to use >=dev-util/cmake-3.2.3 , as there is a musl specific patch in tree. stable in-tree of autogen does not compile and therefore gnutls does not. workaround is to use >=sys-devel/autogen-5.18.4. these are both non-stable packages, so I thought to add them to the DEPEND section of the ebuild. however, these are not direct dependecies, but of app-text/poppler and of net-libs/gnutls or rather of net-libs/neon. is there any clean and smooth way to include them as dependencies in the libreoffice ebuild? >app-text/libetonyek-0.1.1 does not build, neither does >=dev-cpp/libcmis-0.5. however, there is a ugly fix for gcc to solve this problem. for further information, have a look at #559516#c2. last, but not least, =x11-proto/xcb-proto-1.11 fails to build with python 3_3 and python 3_4 bindings. one workaround is to disable the use flag via -python_targets_python3_3 or respectivly -python_targets_python3_4. if that is not appealing to you, have a look at #559520#c4 , take a deep breath, and apply the tiny patch to your musl c-lib. although it seems to work, this does require much more testing I guess.
Created attachment 411236 [details, diff] updated patch against the musl overlay libreoffice-4.4.5.2 is now stable on amd64 and x86.
(In reply to tt_1 from comment #18) > Created attachment 411236 [details, diff] [details, diff] > updated patch against the musl overlay > > libreoffice-4.4.5.2 is now stable on amd64 and x86. committed
"${FILESDIR}/${PN}-4.4.1.2-fix-includes.patch" "${FILESDIR}/${PN}-5.0.5.2-linux-musl.patch" "${FILESDIR}/${PN}-4.4.1.2-musl-fix-execinfo.patch" Hey all, what's the status here? I'll be happy to add patches to our release ebuilds as soon as they have been accepted upstream into master branch. :)
(In reply to Andreas K. Hüttel from comment #20) > "${FILESDIR}/${PN}-4.4.1.2-fix-includes.patch" > "${FILESDIR}/${PN}-5.0.5.2-linux-musl.patch" > "${FILESDIR}/${PN}-4.4.1.2-musl-fix-execinfo.patch" > > > Hey all, what's the status here? > > I'll be happy to add patches to our release ebuilds as soon as they have > been accepted upstream into master branch. :) No response.
Created attachment 798118 [details] build.log.xz (amd64, 7.3.4.2-r1) As libreoffice magically disappeared from ::musl overlay I tried building latest ::gentoo version which worked right on. Also no runtime crashes so far. Also clang buuild works fine. Seems this issue is resolved?
Created attachment 799999 [details, diff] Removes the execinfo dependency from libreoffice's bundled skia This patch allowed me to build libreoffice on an x86_64 gentoo musl system with USE="vulkan". I have reported this same issue to the skia team upstream, however I'm not sure if TDF would be interested in supporting it. This bypasses skia-vulkan's dependency on execinfo.h by simply removing the backtrace code.
As an update, skia upstream fixed the issue triggered by USE="vulkan", so a future LibreOffice update should resolve the issue once it pulls in a newer skia.