Date: Thu, 08 Nov 2012 17:56:34 +0900 (JST) From: Maho NAKATA <chat95@mac.com> To: gerald@pfeifer.com Cc: office@FreeBSD.org Subject: Re: Eliminating use of _GCC_BUILD_DEPENDS from openoffice-3-devel Message-ID: <20121108.175634.255451043250472753.chat95@mac.com> In-Reply-To: <alpine.LNX.2.00.1211060128070.2266@tuna.site> References: <alpine.LNX.2.00.1211031717260.2266@tuna.site> <20121105.155038.872338780898971147.maho@FreeBSD.org> <alpine.LNX.2.00.1211060128070.2266@tuna.site>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@FreeBSD.org>
> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121108.175634.255451043250472753.chat95>