Eliminating use of _GCC_BUILD_DEPENDS from openoffice-3-devel

[Maho NAKATA]

Hi Gerald

> To verify, can you run ldd on the core dumping binary in both
> cases, the one that fails (core dump) and the one that does not
> dump?  And see how that output differs?

On FreeBSD 8.2-RELEASE, amd64 
Non working version:
$ ldd /work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/bin/autodoc
/work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/bin/autodoc:
        libstlport_gcc.so => not found (0x0)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x8008f0000)
        libm.so.5 => /lib/libm.so.5 (0x800b00000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800c20000)
        libthr.so.3 => /lib/libthr.so.3 (0x800d2e000)
        libc.so.7 => /lib/libc.so.7 (0x800e47000)

working version:
$ ldd /work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/bin/autodoc
/work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/bin/autodoc:
        libstlport_gcc.so => not found (0x0)
        libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x8008f0000)
        libm.so.5 => /lib/libm.so.5 (0x800bf3000)
        libgcc_s.so.1 => /usr/local/lib/gcc46/libgcc_s.so.1 (0x800d13000)
        libthr.so.3 => /lib/libthr.so.3 (0x800f28000)
        libc.so.7 => /lib/libc.so.7 (0x801041000)

Yeah, it is expected ;-)

Thanks,
 Nakata Maho

From: Gerald Pfeifer <gerald at pfeifer.com>
Subject: Re: Eliminating use of _GCC_BUILD_DEPENDS from openoffice-3-devel
Date: Tue, 6 Nov 2012 01:33:30 +0100 (CET)

> On Mon, 5 Nov 2012, Maho NAKATA wrote:
>> Without that, building AOO fails at odk module like following:
>> 
>> /usr/local/bin/bash: line 1: 90954 Abort trap: 6           (core dumped) LD_LIBRARY_PATH=/work/tinderbox-ligeti8amd64/portstrees/Fr\
>> eeBSD/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} /work/tinde\
>> rbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/bin/autodoc -html ../..\
>> /unxfbsdx.pro/bin/odkcommon/docs/common/ref -dvgroot "http://wiki.services.openoffice.org/wiki" -name "OpenOffice.org 3.4 API" -lg \
>> idl -dvgfile idl_chapter_refs.txt -t ../../unxfbsdx.pro/bin/odkcommon/idl
>> dmake:  Error code 134, while making '../../unxfbsdx.pro/bin/odkcommon/docs/common/ref/module-ix.html'
> 
> Hmm, a core dump?  That's interesting and indeed points to some 
> incorrect library being used.
> 
> To verify, can you run ldd on the core dumping binary in both
> cases, the one that fails (core dump) and the one that does not
> dump?  And see how that output differs?
> 
> One theory that I can offer from afar, is that the binary is C++
> code, but not linked with LDFLAGS.  Depending on the situation,
> there are two approaches to that:
> 
>  1. Add LDFLAGS.
> 
>  2. In case the binary is not undergoing an extra link step, or
>     that step uses the C++ compiler, the change to Mk/bsd.gcc.mk
>     below that I just committed should help (though only, if then
>     CXXFLAGS is use for that).
> 
> Gerald
> 
> ======== Gerald's commit ========
> From: Gerald Pfeifer <gerald at FreeBSD.org>
> To: ports-committers at freebsd.org, svn-ports-all at freebsd.org, svn-ports-head at freebsd.org
> Date: Tue, 6 Nov 2012 00:23:43 +0000 (UTC)
> Subject: svn commit: r307045 - head/Mk
> X-Spam-Status: No, hits=0.0 required=4.0 tests= autolearn=disabled version=3.002005
> X-Spam-Level: 
> 
> Author: gerald
> Date: Tue Nov  6 00:23:43 2012
> New Revision: 307045
> URL: http://svnweb.freebsd.org/changeset/ports/307045
> 
> Log:
>   In addition to CFLAGS and LDFLAGS now also CXXFLAGS set an rpath to
>   the GCC run-time.
>   
>   This extends revision r246991 (2010-01-02) and should not be necessary
>   in most cases since LDFLAGS already covers linking, but one can always
>   compile and link in one swoop, and this makes things consistent between
>   C and C++.
>   
>   Feature safe:	yes
> 
> Modified:
>   head/Mk/bsd.gcc.mk
> 
> Modified: head/Mk/bsd.gcc.mk
> ==============================================================================
> --- head/Mk/bsd.gcc.mk	Mon Nov  5 22:48:07 2012	(r307044)
> +++ head/Mk/bsd.gcc.mk	Tue Nov  6 00:23:43 2012	(r307045)
> @@ -202,6 +202,7 @@ CPP:=			cpp${V}
>  .   if ${_USE_GCC} != 3.4
>  _GCC_RUNTIME:=		${LOCALBASE}/lib/gcc${V}
>  CFLAGS+=		-Wl,-rpath=${_GCC_RUNTIME}
> +CXXFLAGS+=		-Wl,-rpath=${_GCC_RUNTIME}
>  LDFLAGS+=		-Wl,-rpath=${_GCC_RUNTIME}
>  .    if defined (USE_FORTRAN)
>  .    if ${USE_FORTRAN} == yes
>