32-bit/i386 ports/packges on amd64

[Andriy Gapon]

on 20/03/2007 20:27 Peter Jeremy said the following:
> On 2007-Mar-20 12:00:51 +0200, Andriy Gapon <avg at 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