Created attachment 156448 [details] Enable editors/libreoffice build on powerpc64 The LibreOffice build tools support Linux on PPC64, but FreeBSD only on i386 and AMD64. The included [admittedly rough-edged] patches enable build functionality on the PPC64 platform. Expected result: The port builds Actual result: For starters, the configure script chokes saying that FreeBSD PowerPC64 is not a supported platform. Other issues are encountered later in the build process once the configuration script is updated. Steps to reproduce: Attempt to build LibreOffice on FreeBSD/powerpc64 The included patch is against LibreOffice 4.3.7 on ports tree r385496. The resulting build runs (tested on a PowerMac G5 "Late 2005"). It does not, however, display any icons in the resulting applications; i.e. LibreOffice menu buttons etc. are text-only. Otherwise the build seems to behave agreeably, and it's certainly better than no build at all. Additional patches for the icon issue will be forthcoming if / when I'm able to resolve that problem. Final note: the provided patch enables "USE_GCC= 4.8+" for powerpc64 via the port Makefile because attempting to use base GCC 4.2 was a disaster. Though I have not seen any problems from this myself for LibreOffice, should a linking issue be encountered during ppc64 build after applying the patch, my first guess would be that the LibreOffice build system is attempting to use libc++ from the base system rather than the GCC 4.8 version. If that happens, as a workaround one might try temporarily setting base libg++.so.* aside, symlinking GCC 4.8 libg++.so.6 in its place during LibreOffice build, then restoring the original after the build is complete, as the FreeBSD system linker is a bit wiser about determining dependencies and doesn't seem to suffer from the same problem.
Created attachment 156449 [details] Enable editors/libreoffice build on powerpc64 (revision 2)
This is fantastic! I'm building locally to confirm, and would love to see this pushed into the ports tree. The changes look pretty small, do you think it would apply as cleanly for powerpc (32-bit)?
(In reply to Justin Hibbits from comment #2) TBH I haven't the faintest idea if a similar process could be followed for 32-bit ppc. At first glance I don't see any reason why not; I may throw a 32-bit jail with UNAME_* overrides on my build machine and give it a try. I'd like to get feedback on the patches as they stand first, and address the icon issue as a priority.
Unfortunately my test in poudriere failed, possibly related to your comment regarding libstdc++ mismatches. I'll attach the log. I haven't tried moving the base libraries aside, not sure the best way to do it with poudriere.
Created attachment 156915 [details] poudriere failure log for editors/libreoffice (Compressed because bugzilla rejected the uncompressed log) Specially note: [build LNK] Executable/oosplash [build PRJ] xmlsec /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.3.7.2/instdir/sdk/lib/libuno_sal.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15' collect2: error: ld returned 1 exit status /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.3.7.2/desktop/Executable_oosplash.mk:10: recipe for target '/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.3.7.2/instdir/program/oosplash' failed I checked /usr/local/lib/gcc48/libstdc++.so.6.0.19 does have that symbol, but nm doesn't show if it's annotated with the "GLIBCXX_3.4.15" version.
(In reply to Justin Hibbits from comment #5) I've seen this error before on a ppc64 and sparc64; the error message would seem to confirm my hunch that it would be the result of the LO build system pulling in the system libc++ instead of the gcc48 version, even when using gcc48 to build. In any event, I'll see if I amend my patch to take care of this as well, and resubmit an updated version as soon as is practical.
Created attachment 177718 [details] Patches to provide full powerpc64 support and fix menu and toolbar issues. This is a set of patches that add support for building editors/libreoffice4 on powerpc64. The patches provide a fix for the issues of with missing icons on menus, toolbars and graphics gallery. Other than adding powerpc64 support, the logic for detecting whether to use big endian or little endian was changed to ensure that big endian code is used where appropriate.
Curtis, this is fantastic. Do you think you could make this into a ports patch?
Created attachment 177763 [details] Libreoffice4 ports patch I'm not sure what you mean. Here's a revised patch. But as-is, you can drop the patch file into "libreoffice4/files". You will need to add powerpc64 to the "ONLY_FOR_ARCHS" line in Makefile.
Created attachment 178310 [details] Libreoffice5 ports patch Adding new patch set for Libreoffice5. Patches made against r427743 (2016-12-03)
(In reply to Curtis Hamilton from comment #10) Hi Curtis, Do you have any other instructions for building editors/libreoffice for powerpc64? The last bits of my poudriere log are: [build UIC] desktop /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.2.4.2/instdir/sdk/lib/libuno_sal.so: undefined reference to `std::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned long) const@GLIBCXX_3.4.18' /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.2.4.2/instdir/sdk/lib/libuno_sal.so: undefined reference to `std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const@GLIBCXX_3.4.18' /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.2.4.2/instdir/sdk/lib/libuno_sal.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15' collect2: error: ld returned 1 exit status gmake[2]: *** [/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.2.4.2/desktop/Executable_oosplash.mk:10: /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.2.4.2/instdir/program/oosplash] Error 1 I'll attach the full this evening.
Justin, These type errors usually indicate a mismatch between the 'stdc++' library of the GCC version you're building with and the 'stdc++' library that is being linked against. What GCC version are you using? Do you have the corresponding libraries defined in "/etc/libmap.conf"? Check and ensure that the library that LD is using is the correct one for the GCC version you're using. Regards,
Hi Curtis, I do all my ports builds using ports-mgmt/poudriere, which creates a pristine jail for ports builds, so is a good test for if a patch is ready (can be a little difficult to set up at first, but I like it for my builds, since it doesn't affect the running system until I'm ready to install the ports, so I highly recommend it). This error, being generated in a poudriere jail, typically indicates that it's using gcc49 (from ports) as CC/CXX, but using /usr/bin/gcc for linking. I'm currently running a build via 'poudriere testport' to get a better log and might be able to get a better indication of what's going on then.
I see. Using a jail is a good idea, as long as the jail environment is comparable to the live environment. However, different versions of runtime libraries can cause undesired behaviors. I have the luxury of having two separate systems for building and testing. From what you've stated, I do believe what you are seeing is the difference in the stdc++ libs used by GCC49 and /usr/bin/gcc. Especially, if 'usr/bin/gcc' is the stock GCC distribution. That is why I asked about '/etc/libmap.conf.' You can perform a quick check by checking for the presence, or absence, of 'GLIBCXX_3.4.18' by doing the following: strings /usr/lib/libstdc++*|grep GLIBCXX I've had this happen to me when building a port on one system and installing on another, after upgrading GCC on the build system. BTW, what version of FreeBSD are you using?
Hi Curtis, I'm using FreeBSD 12-CURRENT, as of September (r305820). Regarding /etc/libmap.conf, it should be unnecessary when building with USE_GCC=yes, because the ports framework will set -rpath and other command line arguments appropriately.
Hi Curtis, I just checked libstdc++.a and libstdc++.so in /usr/local/lib/gcc49, and neither have the symbols *@GLIBCXX_3.4.15, the symbols are naked: 0000000000079920 t 00000612.plt_call._ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm 000000000017b410 D _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm 000000000017b428 D _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEmmm 0000000000126d98 r _ZZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEmE10__fast_bkt It does have an absolute symbol of GLIBCXX_3.4.15 0000000000000000 A GLIBCXX_3.4.15
Created attachment 178631 [details] Verbose log of libreoffice 5.2.4 build Here's the full verbose log (modified editors/libreoffice/Makefile to add a "MAKE_ENV += GMAKE_OPTIONS='VERBOSE=1'" line) The offending line was actually: [build LNK] Executable/oosplash S=/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.2.4.2 && I=$S/instdir && W=$S/workdir && gcc49 -Wl,-z,origin '-Wl,-rpath,$ORIGIN' -Wl,-rpath-link,$I/program -fstack-protector-strong -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib -L$I/program -L$I/program -L/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 -L/usr/local/lib/gcc49 -L/usr/local/lib -R/usr/local/lib $W/CObject/desktop/unx/source/args.o $W/CObject/desktop/unx/source/file_image_unx.o $W/CObject/desktop/unx/source/pagein.o $W/CObject/desktop/unx/source/splashx.o $W/CObject/desktop/unx/source/start.o -Wl,--start-group -lXinerama -lX11 -L/usr/local/lib -lpng16 -Wl,--end-group -Wl,--no-as-needed -luno_sal -o $I/program/oosplash
(In reply to Justin Hibbits from comment #16) Of course I meant both GLIBCXX_3.4.15 and GLIBCXX_3.4.18
It's really a guess on my part, but I looks that somehow another library is being used by ld. Are you sure there is no default libstdc++.so in /usr/lib? It could be that the search order of RPATH is finding another library and using it.
(In reply to Curtis Hamilton from comment #19) There is, of course, the system libstdc++.so in /usr/lib. Looking at the command line, it appears libreoffice explicitly adds "-Wl,-rpath-link,/lib:/usr/lib" to the link line, such that /usr/lib/libstdc++ is likely found before /usr/local/lib/gcc49/libstdc++.so . This could end up being just another minor patch to unxgcc.mk .
It looks like it can continue if oosplash is linked with g++6, not gcc6, so a minor patch to unxgcc.mk could just drop the check for C++ objects, and always link with gb_CXX, never with gb_CC. A bit inefficient, but it looks like it should work.
FYI, I'm going to update editors/libreoffice to 6.0.2 in bug 224288 and you may want to update the patch against to it.
A commit references this bug: Author: lwhsu Date: Wed Mar 28 06:59:31 UTC 2018 New revision: 465781 URL: https://svnweb.freebsd.org/changeset/ports/465781 Log: - Fix build on powerpc64 PR: 200020 [1], 226659 [2] Submitted by: gmbroome@vcu.edu [1] Curtis Hamilton <hamiltcl@verizon.net> [2] jhibbits Changes: head/editors/libreoffice/Makefile head/editors/libreoffice/files/patch-powerpc64