sgk at troutmask.apl.washington.edu
Sat Aug 26 19:25:05 UTC 2006
On Sat, Aug 26, 2006 at 02:40:24PM -0400, Mike Meyer wrote:
> In <20060826180900.GA81762 at troutmask.apl.washington.edu>, Steve Kargl <sgk at troutmask.apl.washington.edu> typed:
> > On Sat, Aug 26, 2006 at 02:00:51PM -0400, Mike Meyer wrote:
> > > 1) The compiler can build i386 binaries, but the toolchain in general
> > > doesn't do the right thing with the -m32 flag.
> > I believe that this may be false because the compiler is
> > not built with multilib enabled.
> I'm not sure what you're saying is false - that the compiler can
> generate i386 binaries, or that the rest of the toolchain doesn't do
> the right thing.
> I can build i386 binaries with the system cc. However, if I just
> specify '-m32', it dies during the link because it tries to link with
> amd64 object files. I've managed to get some simple things to build by
> passing the appropriate command line to cc.
> Would rebuilding the compiler with multilibs fix that problem? Or does
> it assume a library structure that isn't in place on FreeBSD?
I believe it is a library structure problem. You need at least
a 32-bit and 64-bit libgcc.so. When you use -m32 the compiler
goes looking for an appropriate libgcc.so and only finds a 64-bit
AFAIK, you can't rebuild the base system compiler with multilib
because it is integrated into the FreeBSD tree without the full
> > > 2) The system can run i386 binaries, but the pkg system doesn't
> > > support installing packages from other architectures.
> > I don't understand your 'but' clause. You can run i386 binaries
> > on amd64. You can install i386 packages on an amd64 system, if
> > the port maintainer hasn't used the arch_only=i386 make variable.
> Yes, I can install the package - but the package system isn't aware
> that there are multiple architectures involved. It always looks in the
> same place for libraries, so if you want to install a 64 bit package
> and a 32 bit package that both require the same library package, one
> of them is going to wind up broken.
> Just to be clear, I'm talking about installing pre-built packages,
> because building i386 packages on amd64 runs into problems during the
> compile, as outlined in #1.
OK. That makes more sense. You are correct that the pkg system
does keep track of dependencies in a way that allows an automatic
install of a 32-bit pkg with its dependencies. You could unpack
the various packages and manually place the files where you need
them (ie libraries in /usr/lib32).
> > > 3) openoffice doesn't build on amd64, and the i386 build doesn't run
> > > on amd64, so the recommended way to run openoffice on amd64 is to
> > > run the Linux build.
> > Openoffice builds just fine on 6.1. You need to specify WITHOUT_MOZILLA.
> Hmm. My copy of the port sets that for amd64 already. Checking the CVS
> repository, it looks like a number of things have broken/unbroken in
> the last few days. In particular, one of the repositories appears to
> have a broken copy of the tarball the port is using. I'll update the
> port, make distclean, and try again.
> In the meantime, could you tell me which openoffice port you build?
> I'm using openoffice.org-2.0, and not the -devel branch.
openoffice.org-2.0.3 Integrated wordprocessor/dbase/spreadsheet/drawing/chart/br
ls -l /usr/local/bin shows that I built the port on 7 Aug 06.
Of course, the port could have been broken in the last 20 days. :(
More information about the freebsd-hackers