32-bit/i386 ports/packges on amd64

[Andriy Gapon]

on 19/03/2007 20:35 Coleman Kane said the following:
> It is not that odd so long as you look at the history of the project(s),
> as i386 FreeBSD binaries work quite fine on FreeBSD/amd64 (providing you
> have the appropriate i386 libraries). In addition, the i386 Linux ports
> work because i386 Linux emulation has been ported over to FreeBSD/amd64.
> The linux-binary ports are just installations that use the linux
> userland in /compat/linux. There could be a /compat/freebsd32 or similar
> to do this.

Well, I understand why Linux/i386 works nice on amd64. And for the same
reason Linux/amd64 doesn't work here yet.
What I don't understand is why we don't have any natural-and-complete
support for FreeBSD/i386, given that it would be easier to do than Linux
emulation. But, of course, Linux emulation was already there :-)

> What many people, including myself, have done is to build a
> package of a port (cd /usr/ports/lang/mit-scheme; make package) on a
> 32-bit machine and then pkg_add the tarball on the new system. Ports is
> really set up to target architectures different from the current one.

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 problem is not the lack of 32-bit support on FreeBSD/amd64 (which
> actually works really well) but the lack of a user-friendly system for
> installing 32 and 64 bit versions of ports from the same ports
> repository and managing them all. In fact, the binary emulation
> infrastructure

I agree with this completely. It would be nice if port/packages systems
were aware of intimate relationship between amd64 and i386 platforms. At
the very least this would require issues #1-4 above to be resolved. It
would be also nice to have a knob for ports to say I am building i386
software/package on amd64 system.
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.


> You could perhaps compile+install your 32-bit freebsd userland (using
> existing infrastructure in /usr/src) into /compat/freebsd32 and then use
> chroot to run 32-bit /compat/freebsd32/bin/tcsh inside of the
> /compat/freebsd32 root. Once there you could have a separate repository
> for ports, as well as a seperate /var/db/pkg for 32-bit packages.

Well, I also saw this as the easiest way to get i386 compatibility. But
reality is not so nice.
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.

Also, I want to be able to execute i386 binaries from normal environment
(without doing chroot), but I am still fighting to resolve problems with
run-time linker: it seems that if some 32-bit lib is not found in
LD_32_LIBRARY_PATH then _sometimes_ ld-elf.so.hints is used instead of
ld-elf32.so.hints. This is very strange.

So, in practice, I couldn't find any way so far to get a native web
browser with java plugin.



-- 
Andriy Gapon