32 bit ports on an AMD64 system

[b. f.]

>> /usr/local/[same-as-before]-32 (i.e. [...]/bin32, [...]/lib32,
>> [...]/libexec32, etc)

>The one above sounds most logical. The base system puts 32 bit libraries in
>/usr/lib32.

It's too much trouble to append a 32 to every subdirectory of
/usr/local/ -- I'd still recommend something like
PREFIX=/usr/local/32, with all relative paths the same.

>Currently the ports system is not set up to handle multiple versions of the
>same port, AFAIK. You could ask on the ports list.

Multiple versions of the same port with different PKGNAME s can be
handled.  Otherwise, no.

>You'd need a separate
>/var/db/pkg32 to store information about installed 32-bit ports. And
>/var/db/ports32 for options for 32-bit ports. You would also need changed port
>makefiles (different /ve/db paths, -m32 flag etc.) for this to work. It should
>be possible, but I don't think anybody has volunteered to do the work yet. :-)

In many cases, the same port Makefile would suffice, using the
make.conf additions I mentioned in my earlier message. In some cases,
you may have to add patches to the port or change the port Makefile.

The point about the package registration is a good one.  It would
certainly be easier to maintain two separate package databases.  To do
so, and to also have different OPTIONS-handling for the 32-bit ports
via separate ports databases, then you could simply add:

PKG_DBDIR=/var/db/pkg32
PORT_DBDIR=/var/db/ports32

to the make.conf block in my last message.

However, I think it would be better to instead maintain unified
package and port databases and somehow differentiate between the
entries for 32-bit and 64-bit packages, by either tinkering with the
fake-pkg target in bsd.port.mk, or, preferably, by changing the
PKGNAME and UNIQUENAME.  The simplest way to do this would be to add a
block like

.ifdef(32BIT)
PKGNAMEPREFIX+=32
.endif

just before the definitions of PKGNAME and UNIQUENAME in bsd.port.mk.

...

>(* 'need' in this case means that you are regularly running out of address
>space on i386.)

Or if you need improved performance from a 64-bit app, etc.

As the I and the others have mentioned, a jail or a separate 32-bit
installation would probably be better.

b.