William Hubbs <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 23 Feb 2007 22:27:38 -0600:
> I'm not familiar with this test, and I jhave a bug against one of the > packages I maintain that says it fails for e package. > > Where do I find information on how to fix the package? As I've seen no dev answer as yet, perhaps this will help? This is a multilib arch (such as but not limited to amd64, with separate 32-bit and 64-bit libdirs) specific issue. Basically, with FEATURES=multilib-strict, emerge will bail with an error if it finds one of a particular list of filetypes going into lib instead of the sub-arch appropriate libdir. See the multilib and multilib-strict settings in profiles/default-linux/amd64/make.defaults for an example of the profile settings, in this case for amd64. The helper functions and documentation you want are found in multilib.eclass (but you'll probably simply inherit eutils, which in turn inherits multilib). For simple cases (as it appears you already know, being maintainer of packages that use it), it's likely all you'll need to do is inherit eutils and call .configure with an option setting libdir, using the eclass's get_libdir function. For more information, check with the amd64 arch devs, as that's who has done most of the work on the eclass, AFAIK, altho it is now apparently used by mips64, ppc64, s390x, and sparc64, as well. The definitive simple case example: skel.ebuild The definitive complex case example (where a multilib profile will have multiple instances, one for each subarch, installed to separate locations by the same ebuild): sys-libs/glibc A quick grep for get_libdir shows several app-accessibility packages already using it, including at least one with you as maintainer, so I take it the problem goes a bit beyond the simple case, and you may need to talk to an amd64 or other bug-arch specific dev about it. -- 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 -- gentoo-dev@gentoo.org mailing list
