>> /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

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:


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


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.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to