Re: amd64 questions

In <20060826192418.GA82155@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Steve Kargl <sgk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> typed:
On Sat, Aug 26, 2006 at 02:40:24PM -0400, Mike Meyer wrote:
In <20060826180900.GA81762@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Steve Kargl <sgk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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
version.

Yup. If you tell it -L/usr/lib32 (which gets installed if you build the
world with WITH_LIB32 defined), it'll find that. Then complain because
/lib/crt1.o is the 64 bit one. If I use the command line arguments:

-m32 -nostartfiles /usr/lib32/crt1.o /usr/lib32/crti.o /usr/lib32/crtbegin.o /usr/lib32/crtend.o /usr/lib32/crtn.o -L/usr/lib32

simple programs build and run properly.

AFAIK, you can't rebuild the base system compiler with multilib
because it is integrated into the FreeBSD tree without the full
gcc configury.

How about the various gcc's in the ports tree? How much pain would be
involved in getting one of those to build/install so that a simple
"-m32" would do "the right thing?"

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.
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).

I assume you mean "does not", instead of "does". For simple packages,
this works. For complex ones - like openoffice - it gets pretty
painfull. The question is, is this something that we want to fix? [And
since I was leading up to this kind of question, I figured -hackers
was the right place to start this.].

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.

pkg_info shows
openoffice.org-2.0.3 Integrated wordprocessor/dbase/spread***/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. :(

Actually, I'm hoping the real problem was that one of the ftp sites
had a broken tarball, and I grabbed that. I'm still working on it.

Just out of curiosity, what are the chances of getting you to build a
package/tarball out of what you've built, since there isn't a package
availabe from the freebsd ftp sites? I'd be willing to make it
available for others to download.

Thanks,
<mike
--
Mike Meyer <mwm@xxxxxxxxx> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"