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
What |Removed |Added
CC| |[hidden email]
--- Comment #2 from Justin Hibbits <[hidden email]> ---
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 from [hidden email] ---
(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 from Justin Hibbits <[hidden email]> ---
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 #6 from [hidden email] ---
(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.
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 from Curtis Hamilton <[hidden email]> ---
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.
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:
000000000017b410 D _ZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEm
000000000017b428 D _ZNKSt8__detail20_Prime_rehash_policy14_M_need_rehashEmmm
--- Comment #19 from Curtis Hamilton <[hidden email]> ---
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