Date: Wed, 21 Mar 2007 14:49:33 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit/i386 ports/packges on amd64 Message-ID: <460129DD.5010107@icyb.net.ua> In-Reply-To: <20070320182749.GG76696@turion.vk2pj.dyndns.org> References: <45FE7615.3090606@icyb.net.ua> <ab581e310703190929x269bc9a3w364f801fbeff8b0e@mail.gmail.com> <346a80220703191135w3e4fdb92ic8c93a38ff37f15a@mail.gmail.com> <45FFB0D3.8030201@icyb.net.ua> <20070320182749.GG76696@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 20/03/2007 20:27 Peter Jeremy said the following:
> On 2007-Mar-20 12:00:51 +0200, Andriy Gapon <avg@icyb.net.ua> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?460129DD.5010107>