From owner-freebsd-ports@FreeBSD.ORG Thu Feb 28 22:04:25 2008 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD60E106566B for ; Thu, 28 Feb 2008 22:04:25 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 7D40A8FC19 for ; Thu, 28 Feb 2008 22:04:24 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [77.41.69.16] (helo=[172.16.100.3]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1JUqvb-0000le-0y; Fri, 29 Feb 2008 01:08:35 +0300 Message-ID: <47C72FE6.4030408@FreeBSD.org> Date: Fri, 29 Feb 2008 01:04:22 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Kris Kennaway References: <47C6701C.2090009@FreeBSD.org> <47C725F5.1070503@FreeBSD.org> In-Reply-To: <47C725F5.1070503@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org Subject: Re: misc/compat6x X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 22:04:25 -0000 Kris Kennaway wrote: > Sergey Matveychuk wrote: >> Hi. >> >> I tried to start an application on 7.0 that requires libpthread.so.2. >> I've installed misc/compat6x, but have a problem: >> /usr/local/lib/compat/libpthread.so.2: Undefined symbol >> "__malloc_lock"Could not load addin module >> "/usr/local/lib/libtfmessbsp.so"! >> >> As I can see __malloc_lock symbol is in libc.so.6 from compat6x port >> but does not load. Why? Any ideas how to fix it? > > How is libc.so.6 being loaded by the application? Is it linked > explicitly or is it (incorrectly) trying to dlopen("libc.so") or similar? % ldd /usr/local/lib/libtfmessbsp.so /usr/local/lib/libtfmessbsp.so: libbioapi_mds300.so.0 => /usr/local/lib/libbioapi_mds300.so.0 (0x281a2000) libusb-0.1.so.8 => /usr/local/lib/libusb-0.1.so.8 (0x281c4000) libintl.so.6 => /usr/local/lib/libintl.so.6 (0x281ca000) libmds_util.so.0 => /usr/local/lib/libmds_util.so.0 (0x281d3000) libpthread.so.2 => /usr/local/lib/compat/libpthread.so.2 (0x281db000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x28300000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x2830e000) libthr.so.3 => /lib/libthr.so.3 (0x283fc000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2840f000) libm.so.5 => /lib/libm.so.5 (0x28504000) libc.so.7 => /lib/libc.so.7 (0x28089000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2851a000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28525000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x2861b000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x2861e000) librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x28623000) The library is not linked with libc. But dynamic loader loads libc.so.7 for libthr.so.3. kib@ has told me it's impossible to fix (we can't mix libc.so.6 and libc.so.7 in one namespace). So we should ask vendor to recompile it for 7.0 (it's security/bsp_upektfmess). -- Dixi. Sem.