Date: Sun, 24 Aug 2014 11:39:54 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: pfg@FreeBSD.org Cc: office@FreeBSD.org Subject: Re: OpenOffice 4.1 build persistently fails on my FreeBSD-10-stable/AMD64 Message-ID: <201408241839.s7OIdsd9055757@gw.catspoiler.org> In-Reply-To: <2366E5BA-9FD3-4243-9C47-F92B68F8C3A6@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Aug, Pedro Giffuni wrote: > > Il giorno 23/ago/2014, alle ore 20:32, Don Lewis > <truckman@FreeBSD.org> ha scritto: > >> On 23 Aug, Pedro Giffuni wrote: >>> >>> On 08/23/14 13:51, Don Lewis wrote: >>>> On 22 Aug, Pedro Giffuni wrote: >>>>> FWIW, >>>>> >>>>> AOO 4.1 is known to have bugs and AOO 4.1.1 will be released >>>>>really soon to address them. The patch in PR 192545 unbreaks the >>>>>AOO 4.1.0 build on FreeBSD 10 and >>>> 11: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192545>; >>>> >>>> The patch in PR 192557 upgrades openoffice-devel to 4.1.1-RC3: >>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192557>; >>>> >>> >>> The patch in PR 181044 fixes Boost so that it can be used as >>> an external dependency for OpenOffice: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181044 >> >> Still no joy B-( >> >> When I was first working on 4.1.0, I ran into the #include_next >> problem and tried to work around it by adding >> -DBOOST_TR1_DISABLE_INCLUDE_NEXT to CFLAGS. The errors still >> occurred, but with different message text. >> >> With this patch applied, I see the same thing as in my earlier >> experiments: >> >> In file included from /usr/local/include/boost/tr1/tr1/vector:16:0, >> from >> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.1.1/main/solver/411/unxfbsdx.pro/inc/stl/vector:31, >> from >> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.1.1/main/xml2cmp/source/finder/dependy.hxx:28, >> from >> /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.1.1/main/xml2cmp/source/finder/dependy.cxx:25: >> /usr/local/include/boost/tr1/detail/config_all.hpp:163:41: fatal >> error: ../4.7/utility: No such file or directory compilation >> terminated. > > Ugh… this looks familiar :( > > The problem is really messy: the original OpenOffice was developed in > the dark ages of C++ libraries and used STLport as it’s STL > implementation. STLport doesn’t work with modern compilers (like in > MacOSX) so Boost is very handy because it has TR1 implementation which > can be very useful to complement older versions of libstdc++. With a > good native STL library, AOO makes very little use, if any, of boost. > > In order to be less disruptive, AOO has some wrappers for the STL > libraries in main/stlport/systemstl and for some reason this works > fine on for linux, Windows and MacOSX but it always gets those wrong > on FreeBSD. > > AOO appears to be the only package that exercises include_next because > the definition was wrong before my patch and no one had noticed. The > explanation is here: > > https://svn.boost.org/trac/boost/ticket/8944 > > Perhaps the path may need adjusting for gcc4.7. Extra eyes are > certainly welcome. main/solver/411/unxfbsdx.pro/inc/stl/vector contains this: #ifdef HAVE_STL_INCLUDE_PATH // TODO: use computed include file name #include_next <vector> #elif defined(_MSC_VER) #include <../../VC/include/vector> #else // fall back to boost/tr1 #include <boost/tr1/tr1/vector> #endif which gets us into boost and it's emulation of #include_next. If we were using our old gcc 4.2 in base, then we'd want to pick up the second of these: %find /usr/include -name vector -print /usr/include/c++/4.2/debug/vector /usr/include/c++/4.2/vector so your patch would work. Using gcc 4.7, we want the last one of these: %find /usr/local/lib/gcc47/include -name vector -print /usr/local/lib/gcc47/include/c++/profile/vector /usr/local/lib/gcc47/include/c++/debug/vector /usr/local/lib/gcc47/include/c++/vector If I tweak the path in your patch to this: +# define BOOST_TR1_STD_HEADER(name) <../c++/name> I can successfully build OpenOffice with system boost. It looks like this should also work with the gcc 4.6 port. If you tweak your patch to distinguish between gcc 4.2 and later versions and select the path accordingly, it should work for all cases. Back to the original build failure ... for some reason unopkg.bin is segfaulting when linked with the system libgraphite. I noticed that the silgraphite port picked up one of the patches silgraphite patches from OpenOffice with some tweaks, but not the rest. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run Starting program: /mnt2/tmp/mnt2/usr/ports/editors/openoffice-devel/work/aoo-4.1.1/main/instsetoo_native/unxfbsdi.pro/Apache_OpenOffice/archive/install/en-US_witherror/Apache_OpenOffice_4.1.1_FreeBSD_install-arc_en-US/openoffice4/program/unopkg.bin [New LWP 100780] [New Thread 8a803080 (LWP 100780/unopkg.bin)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8a803080 (LWP 100780/unopkg.bin)] 0x00000000 in ?? () (gdb) tr trace command requires an argument (gdb) bt #0 0x00000000 in ?? () #1 0x88290bf4 in __dynamic_cast (src_ptr=0x8832fc40, src_type=0x88326684, dst_type=0x88326540, src2dst=0) at ../../.././../gcc-4.7.4/libstdc++-v3/libsupc++/dyncast.cc:61 #2 0x882bf021 in std::has_facet<std::ctype<char> > (__loc=@0x8832f9b0) at locale_classes.tcc:257 #3 0x882b273a in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale (this=0x8832f944, __loc=@0x8832f9b0) at basic_ios.tcc:160 #4 0x882b27e9 in std::basic_ios<char, std::char_traits<char> >::init ( this=0x8832f944, __sb=0x8832f540) at basic_ios.tcc:133 #5 0x882a42c3 in std::ios_base::Init::Init (this=0x8853264c) at ostream:83 #6 0x8832f944 in std::cout () from /usr/local/lib/gcc47/libstdc++.so.6 #7 0x8832f540 in __gnu_internal::buf_cin_sync () from /usr/local/lib/gcc47/libstdc++.so.6 Previous frame inner to this frame (corrupt stack?)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408241839.s7OIdsd9055757>