From owner-freebsd-office@FreeBSD.ORG Tue Nov 6 00:33:34 2012 Return-Path: Delivered-To: office@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC27811C; Tue, 6 Nov 2012 00:33:34 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) by mx1.freebsd.org (Postfix) with ESMTP id B71048FC0C; Tue, 6 Nov 2012 00:33:34 +0000 (UTC) Received: from ip-109-84-49-60.web.vodafone.de (ip-109-84-49-60.web.vodafone.de [109.84.49.60]) by ainaz.pair.com (Postfix) with ESMTPSA id E0E873F412; Mon, 5 Nov 2012 19:33:26 -0500 (EST) Date: Tue, 6 Nov 2012 01:33:30 +0100 (CET) From: Gerald Pfeifer To: Maho NAKATA Subject: Re: Eliminating use of _GCC_BUILD_DEPENDS from openoffice-3-devel In-Reply-To: <20121105.155038.872338780898971147.maho@FreeBSD.org> Message-ID: References: <20121105.155038.872338780898971147.maho@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: office@FreeBSD.org X-BeenThere: freebsd-office@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Office applications on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:33:35 -0000 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 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