antoine posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 24 May 2005 03:39:18 +0100:
> I would like to compile libpcap.so as a 32-bit library without using a > chroot, I thought that using 'CFLAGS="-O2 -m32" emerge -v libpcap' would > do it, but if fails at: > checking if --disable-protochain option is specified... enabled > configure: error: pcap type not determined when cross-compiling; use > --with-pcap=... > Any idea how to get it to compile using emerge? > (compiling from source works fine using: > ./configure --prefix=/usr --host=x86_64-pc-linux-gnu > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib32 > --disable-ipv6) The thing is you probably don't /want/ to get it running using emerge, as it will royally screw your dependencies, because portage will then have no idea what libraries are 32-bit and which are 64-bit -- it'll just have them as one big jumbled list, because at present, it doesn't and can't track them separately. (In theory, you could keep a 32-bit and a 64-bit copy of /var/db/, manually switching them when you switch what you are compiling, but in reality, it's then probably simply easier to do the chroot thing, particularly since that's at least understood and decently supported by the Gentoo amd64 devs and others on this list.) Currently, other than using a chroot, doing the tarball thing manually IS the supported method of installing 32-bit stuff. The Gentoo amd64 technotes have BIG warnings about how attempting to use portage to manage 32-bit stuff outside of a chroot, on a 64-bit system, WILL screw it portage's dependency tracking. They say NOT to come looking for support if you are doing it anyway, because it's KNOWN to break systems, and when yours breaks (as it very likely will if you do this), you get to keep the pieces! FWIW, this is going to be changing in the future. The goal is to have a decently working multi-bitness tracking portage up and running by 2005.1, scheduled for release sometime 2H. I'm guessing there will however remain minor issues with individual libraries under that system until 2006.0, next year's first release. This multi-bitness tracking will require the upcoming version of portage, however, which isn't yet publicly available even as a testing-masked alpha-ebuild, and (judging by the 2.0.50 to 2.0.51 testing and upgrade cycle) it's likely to require at least a couple month's testing at that level and as a testing-mask beta, before it's available at ~arch, plus another month there b4 it goes stable arch. Thus, we are looking at probably Sept. at the very earliest, before it'd be considered stable enough for release rollout. That would put the actual release in October, most likely, if not later. That's still assuming they don't run into major issues with what is after all a major feature addition, and end up punting multi-bitness tracking into 2006. In any case, tho, it's coming. It's just not here yet, and there's still some distance to go b4 we see it, but yes, the journey /is/ underway, with the destination targeted on the map and on radar, if not actually in sight, just yet. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
