From owner-freebsd-openoffice@FreeBSD.ORG Sun Jan 29 21:40:06 2006 Return-Path: X-Original-To: openoffice@hub.freebsd.org Delivered-To: freebsd-openoffice@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48A1B16A420 for ; Sun, 29 Jan 2006 21:40:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6A6D43D58 for ; Sun, 29 Jan 2006 21:40:05 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0TLe5pu042344 for ; Sun, 29 Jan 2006 21:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0TLe519042343; Sun, 29 Jan 2006 21:40:05 GMT (envelope-from gnats) Date: Sun, 29 Jan 2006 21:40:05 GMT Message-Id: <200601292140.k0TLe519042343@freefall.freebsd.org> To: openoffice@FreeBSD.org From: Mike Durian Cc: Subject: Re: ports/92218: openoffice.org-2.0 build fails with shlibsign core dump X-BeenThere: freebsd-openoffice@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mike Durian List-Id: Porting OpenOffice to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 21:40:06 -0000 The following reply was made to PR ports/92218; it has been noted by GNATS. From: Mike Durian To: bug-followup@freebsd.org Cc: Subject: Re: ports/92218: openoffice.org-2.0 build fails with shlibsign core dump Date: Sun, 29 Jan 2006 14:31:18 -0700 Well, removing lang/gcc-ooo so it could be rebuilt did not help. I still get the unresolved __usleep symbol, but I think I see what is really going on. I've been using and upgrading FreeBSD for quite a while now and there were some symbolic links in /lib dated from 2003 that probably should have been removed at some point. In paticular, /lib/libc.so was a link to /lib/libc.so.5 When building with the stock system compiler, ld searches /usr/lib for libraries. The ld from gcc-ooo search /lib before /usr/lib. So when I linked with the system ld it found /usr/lib/libc.so which is a link to /lib/libc.so.6. /lib/libc.so.6 resolves __usleep. The ld from gcc-ooo found /lib/libc.so which is a link to libc.so.5. libc.so.5 does not resolve __usleep and thus causes the test for pthread_create in -lpthread to fail. I have removed the symbolic links in /lib and I'll see how thing go. Conceivably, it might be worth adjusting the gcc-ooo linker to use the same search behavior as the stock system linker to avoid this sort of confusion in the future. mike