OpenOffice 4.1 build persistently fails on my FreeBSD-10-stable/AMD64

Sun Aug 24 19:50:18 UTC 2014

Hi Don;

Il giorno 24/ago/2014, alle ore 13:39, Don Lewis <truckman at FreeBSD.org> ha scritto:

> On 23 Aug, Pedro Giffuni wrote:
>> 
>> Il giorno 23/ago/2014, alle ore 20:32, Don Lewis
>> <truckman at 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.
> 
> 

FWIW, this doesn’t work with libc++. I recall I had to define HAVE_STL_INCLUDE_PATH
manually to start the build with libc++.

> 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.
> 
> 

OK. This makes sense: when I was working on this my main interest was to keep building
AOO with the base compiler in FreeBSD 9.

> 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
> 

This is really ugly: includes under the lib directory are probably against out heir(7) structure.
The explanation is that it is not the base compiler, of course, and having them in
/usr/local/include may cause collisions with the compiler in base.

> 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.
> 

I would really prefer not to tweak Boost for this. The truth is the include_next
trick is only meant to cover for deficiencies in the base compiler. The real fix
would be using libc++, but since we cant at this time, a valid workaround
would be accounting for that within AOO in the STLport wrapper
(not sure if that will be something easy though).

> 
> 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.
> 

The vast majority of the libgraphite patches in AOO were meant to account
for STLport, and were not needed in the port. I do see AOO has made at least
two important fixes that we should merge:
http://svn.apache.org/viewvc/openoffice/trunk/main/graphite/?view=log

All in all … you could also turn off silgraphite and leave it as an option:
FreeType improved a lot the Adobe support lately and there are not many
graphite enabled fonts anyways.

Pedro.

> 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?)