32 bit ports on an AMD64 system

b. f. bf1783 at googlemail.com
Tue Sep 1 17:39:42 UTC 2009

You've given some of your reasons for using amd64 -- but are your
reasons for using 32-bit binaries on amd64 strong enough to make all
of this worthwhile?  Why not just use 64-bit binaries for all but the
32-bit-only ports?  Sure, some 32-bit applications will actually run
faster (the opposite is also often true) or use fewer resources, but
is it worth the hassle?

As for your earlier question, I haven't used multiple instances of X
myself, either in or out of jails, but I have seen reports of others
doing so, so I think it is possible, except perhaps in a few cases
where hardware balks because the graphics driver isn't good enough.  I
guess you'll have to make some experiments.  If you don't make
provisions for running a 32-bit X, then is there much point to having,
for example, 32-bit window managers, windowing toolkits, or GUIs?  If
you use a different LOCALBASE for 32-bit ports, you are going to have
to use 32-bit versions of most trunk and branch ports.

I still think a jail is your best bet -- after all, a "thin" jail,
which reuses those portions of your system that don't need to be
different inside the jail,  is just a more thorough version of what
you had hoped to accomplish with your 32-bit shell scripts. If you
don't use a jail ... well, I have not tried to install a large number
of 32-bit and 64-bit ports in parallel, so I am not sure if the
default setup for our loader will make the appropriate distinctions
between 32-bit and 64-bit versions of the same libraries depending
upon the executables or libraries that need them, but I think that
there is a good chance that it will not, and that you will have to do
some extra work to make sure that it does. In the case that it does
not, your only alternative is to either patch a large number of ports
(very time-consuming and error-prone), or to add loader environment
variables to your 32-bit shell scripts to make the loader look in the
32-bit library directories first, or to write a custom loader script
to only load the appropriate libraries depending upon whether the
executable or library that needs them  is 32-bit or 64-bit.  It would
be nice to have this flexibility, but given the current state of the
base system and infrastructure, it just seems like more trouble than
it is worth.


On 9/1/09, Jim <stapleton.41 at gmail.com> wrote:
>>> [...] but the ability to use extra memory *and* dynamically load
>>> kernel modules is a bit more important to me.
>> All FreeBSD supported platforms can dynamically load native kernel
>> modules, so
>> why should that be a factor in choosing between i386 and amd64?
>> Roland
> I didn't specify just loading modules, but extra memory as well (the
> beyond 4GB addressable space). Using the options in i386 that allow
> you to access memory beyond 4GB, also eliminates the ability to
> dynamically load kernel modules.
> -Jim Stapleton

More information about the freebsd-questions mailing list