On Sat, Aug 26, 2006 at 03:43:26PM -0400, Mike Meyer wrote:
> In <20060826192418.GA82155@troutmask.apl.washington.edu>, Steve Kargl <firstname.lastname@example.org> typed:
>> On Sat, Aug 26, 2006 at 02:40:24PM -0400, Mike Meyer wrote:
>>> 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
> 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.
If gcc is built with multilib, it's my understanding that you
don't need to do all of this commandline mangling.
>> 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?"
I've never tried. I build GCC from svn source, but only i386 or
amd64. You should be able to modify a ports Makefile and
--enable-multilib to configure_args. You may need install a
new toolchain as well.
>>> 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.].
You probably want to take this to freebsd-ports.
>>> 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
>> 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. :(
> 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.
The chances are slim. I'm fairly certain that I deleted everything
after the installation (ie., tarballs, build directories, dependencies).
I'll check, but don't hold your breath. :(