>> /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
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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"