From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 21 12:49:50 2007 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2743916A403 for ; Wed, 21 Mar 2007 12:49:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from gateway.cybervisiontech.com.ua (gateway.cybervisiontech.com.ua [88.81.251.18]) by mx1.freebsd.org (Postfix) with ESMTP id 86BDF13C4B8 for ; Wed, 21 Mar 2007 12:49:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (hq.cybervisiontech.com [127.0.0.1]) by gateway.cybervisiontech.com.ua (Postfix) with ESMTP id 7700DED4ACE; Wed, 21 Mar 2007 14:49:37 +0200 (EET) X-Virus-Scanned: amavisd-new at cybervisiontech.com Received: from gateway.cybervisiontech.com.ua ([127.0.0.1]) by localhost (hq.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a76C2Qay7Ud; Wed, 21 Mar 2007 14:49:30 +0200 (EET) Received: from [10.2.1.87] (rein.cybervisiontech.com.ua [10.2.1.87]) by gateway.cybervisiontech.com.ua (Postfix) with ESMTP id 51DD8ED4AC8; Wed, 21 Mar 2007 14:49:30 +0200 (EET) Message-ID: <460129DD.5010107@icyb.net.ua> Date: Wed, 21 Mar 2007 14:49:33 +0200 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.10 (X11/20070315) MIME-Version: 1.0 To: Peter Jeremy References: <45FE7615.3090606@icyb.net.ua> <346a80220703191135w3e4fdb92ic8c93a38ff37f15a@mail.gmail.com> <45FFB0D3.8030201@icyb.net.ua> <20070320182749.GG76696@turion.vk2pj.dyndns.org> In-Reply-To: <20070320182749.GG76696@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit/i386 ports/packges on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 12:49:50 -0000 on 20/03/2007 20:27 Peter Jeremy said the following: > On 2007-Mar-20 12:00:51 +0200, Andriy Gapon wrote: >> Well the problem with this approach is that you can't have both amd64 >> and i386 versions of the same package installed. >> At least a few problems here are as follows: >> 1. package name doesn't include platform, so packages conflict even on >> pkgdb level >> 2. files are installed into the same locations >> 3. properly tracking dependencies is also not possible because of #1 >> 4. even if all i386 and all amd64 packages are unrelated then there >> still can be problems because of i386 shared libraries being installed >> into 64-bit "lib" directories and thus not visible to run-time linker. > > The solution to all these problems is to have two different sets of > hierarchies. The easiest would be /var/db/pkg32, /usr/X11R632 and > /usr/local32 (and maybe /var/db/ports32). This means that the > hierarchy within the ports/packages doesn't change, just the base > directory. The location choice would need to be controlled by a flag > (eg '-32') on the pkg* tools since there's easy way to distinguish > between different architectures within packages. (Packages get > unpacked into temporary directories so maybe an architecture flag > within +CONTENTS would be useful, though some packages are architecture > independent). Totally separate /compat/ia32 directory doesn't seem too bad to me either. That's where I currently keep i386 base system and chroot-install i386 packages. >> There is another problem with arch specification in ports: currently >> i386-only is used to mean several different things - (1) software indeed >> makes sense only on i386 platform; (2) software is actually a thirdparty >> i386 binary; (3) software is not 64-bit clean. > > Is this such a problem? An amd64 in 32-bit mode looks mostly like an > i386 so there any need to distiguish these sub-classes. Well, now I think that you are right, this is not so important in practice. >> As Peter Jeremy already mentioned 32-bit Java is not running on amd64, >> even in such a chroot-ed environment. For me it either crashes or hangs. > > I didn't mention it but the way forward for this is for someone > interested to develop small test cases that don't work so the > underlying cause can be tracked down. Java is such a big app that > just saying it doesn't work isn't helpful. OTOH, a 50 line test > program that doesn't work would be manageable. > It's definitely something about threading. Today I managed to execute i386 diablo-1.5.0_07-b01 java using the following command line (sorry for possible broken lines): $ env LD_32_LIBRARY_PATH=/compat/ia32/usr/local/diablo-jre1.5.0/lib/i386/client:/compat/ia32/usr/local/diablo-jre1.5.0/lib/i386 /compat/ia32/usr/local/diablo-jre1.5.0/bin/java -version with the following ldconfig configuration: $ ldconfig -32 -r | head /var/run/ld-elf32.so.hints: search directories: /compat/ia32/lib:/compat/ia32/usr/lib:/compat/ia32/usr/lib/compat:/compat/ia32/usr/X11R6/lib:/compat/ia32/usr/local/lib:/compat/ia32/usr/local/lib/compat/pkg:/usr/local/lib/compat/pkg and the following lines in libmap32.conf: libthr.so.2 libc_r.so.6 # Everything that uses 'libc_r' libthr.so libc_r.so.6 # now uses 'libthr' libpthread.so.2 libc_r.so.6 # Everything that uses 'libpthread' libpthread.so libc_r.so.6 # now uses 'libthr' Using libpthread results SIGSEGV. ktrace -d -i: 1200 java CALL kse_create(0x812d60c,0x1) 1200 java RET kse_create 0 1200 java CALL __sysctl(0xffffc708,0x2,0xffffc710,0xffffc704,0x280b663c,0x18) 1200 java RET __sysctl 0 1200 java CALL __sysctl(0xffffc710,0x3,0xffffc7bc,0xffffc7c0,0,0) 1200 java RET __sysctl 0 1200 java CALL break(0x8134000) 1200 java RET break 0 1200 java CALL mmap(0xffcbc000,0x41000,0x3,0x400,0xffffffff,0,0,0) 1200 java RET mmap -3424256/0xffcbc000 1200 java CALL mprotect(0xffcbc000,0x1000,0) 1200 java RET mprotect 0 1200 java CALL clock_gettime(0,0x805af5c) 1200 java RET clock_gettime 0 1200 java RET fork 0 <<<======================= What's this ??? 1200 java PSIG SIGSEGV caught handler=0x280a3a24 mask=0xfffefaff code=0xc gdb: #0 0x08130002 in ?? () [New Thread 0x805c01408067a00 (runnable)] [New Thread 0x280b71c808067800 (runnable)] [New Thread 0x8067a140805c000 (sleeping)] Cannot get thread info: generic error (gdb) bt #0 0x08130002 in ?? () (gdb) i thr Cannot get thread info: generic error (gdb) Side-note: is it correct that when gdb opens i386 program and core file it loads ld-elf.so, not ld-elf32.so ? Using libthr results in "Bad system call". (WTF? it's the same OS and the same release): 1197 java CALL _umtx_op 1197 java RET _umtx_op -1 errno 78 Function not implemented 1197 java PSIG SIGSYS SIG_DFL I think that this is something that needs to be fixed very first if we are talking about amd64 binary compatibility with i386. BTW, I've also got opera running in a similar fashion (using libc_r). Unfortunately it SIGSEGVs when it tries to execute java applets. It looks like the problem might be somewhere in dl* (dlopen/dlinfo) area. When I tried opera with libpthread it SIGSEGVed with the following frames: #0 0x29116925 in close () from /compat/ia32/lib/libpthread.so.2 #1 0x28b6e1cb in QProcessPrivate::~QProcessPrivate () from /compat/ia32/usr/X11R6/lib/libqt-mt.so.3 #2 0x28b6edd9 in QProcess::~QProcess () from /compat/ia32/usr/X11R6/lib/libqt-mt.so.3 -- Andriy Gapon