Bug 200020 - [patch] editors/libreoffice: enable build on powerpc64
Summary: [patch] editors/libreoffice: enable build on powerpc64
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Some People
Assignee: FreeBSD Office Team
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2015-05-07 00:22 UTC by gmbroome
Modified: 2018-03-28 07:00 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (office)


Attachments
Enable editors/libreoffice build on powerpc64 (4.86 KB, patch)
2015-05-07 00:22 UTC, gmbroome
no flags Details | Diff
Enable editors/libreoffice build on powerpc64 (revision 2) (4.77 KB, patch)
2015-05-07 00:26 UTC, gmbroome
no flags Details | Diff
poudriere failure log for editors/libreoffice (62.40 KB, application/x-gzip)
2015-05-18 20:45 UTC, Justin Hibbits
no flags Details
Patches to provide full powerpc64 support and fix menu and toolbar issues. (70.58 KB, patch)
2016-12-06 13:20 UTC, Curtis Hamilton
no flags Details | Diff
Libreoffice4 ports patch (73.26 KB, patch)
2016-12-07 19:00 UTC, Curtis Hamilton
no flags Details | Diff
Libreoffice5 ports patch (6.46 KB, patch)
2016-12-27 03:27 UTC, Curtis Hamilton
no flags Details | Diff
Verbose log of libreoffice 5.2.4 build (236.16 KB, application/x-gzip)
2017-01-08 20:18 UTC, Justin Hibbits
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description gmbroome 2015-05-07 00:22:52 UTC
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.
Comment 1 gmbroome 2015-05-07 00:26:56 UTC
Created attachment 156449 [details]
Enable editors/libreoffice build on powerpc64 (revision 2)
Comment 2 Justin Hibbits freebsd_committer 2015-05-07 05:28:43 UTC
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)?
Comment 3 gmbroome 2015-05-07 12:06:58 UTC
(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.
Comment 4 Justin Hibbits freebsd_committer 2015-05-18 20:35:20 UTC
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.
Comment 5 Justin Hibbits freebsd_committer 2015-05-18 20:45:10 UTC
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.
Comment 6 gmbroome 2015-05-22 16:57:52 UTC
(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.
Comment 7 Curtis Hamilton 2016-12-06 13:20:02 UTC
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.
Comment 8 Justin Hibbits freebsd_committer 2016-12-07 16:10:52 UTC
Curtis, this is fantastic.  Do you think you could make this into a ports patch?
Comment 9 Curtis Hamilton 2016-12-07 19:00:16 UTC
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.
Comment 10 Curtis Hamilton 2016-12-27 03:27:52 UTC
Created attachment 178310 [details]
Libreoffice5 ports patch

Adding new patch set for Libreoffice5. Patches made against r427743 (2016-12-03)
Comment 11 Justin Hibbits freebsd_committer 2017-01-05 21:05:01 UTC
(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.
Comment 12 Curtis Hamilton 2017-01-07 01:14:54 UTC
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,
Comment 13 Justin Hibbits freebsd_committer 2017-01-08 03:14:04 UTC
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.
Comment 14 Curtis Hamilton 2017-01-08 05:24:36 UTC
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?
Comment 15 Justin Hibbits freebsd_committer 2017-01-08 16:45:51 UTC
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.
Comment 16 Justin Hibbits freebsd_committer 2017-01-08 20:15:34 UTC
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
Comment 17 Justin Hibbits freebsd_committer 2017-01-08 20:18:05 UTC
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
Comment 18 Justin Hibbits freebsd_committer 2017-01-08 20:20:00 UTC
(In reply to Justin Hibbits from comment #16)

Of course I meant both GLIBCXX_3.4.15 and GLIBCXX_3.4.18
Comment 19 Curtis Hamilton 2017-01-10 02:00:31 UTC
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.
Comment 20 Justin Hibbits freebsd_committer 2017-01-11 02:38:00 UTC
(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 .
Comment 21 Justin Hibbits freebsd_committer 2018-03-12 20:27:32 UTC
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.
Comment 22 Li-Wen Hsu freebsd_committer 2018-03-13 03:28:58 UTC
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.
Comment 23 commit-hook freebsd_committer 2018-03-28 06:59:35 UTC
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