On Sat, Nov 15, 2008 at 12:37 PM, Charles Plessy <[EMAIL PROTECTED]> wrote:
> I am working on a package that, when unmodified, fails on 32bits arches > because > -m64 is in the CFLAGS. We solved the problem by patching the configure file, > but of course this breaks when new upstream releases refresh it with newer > versions of autoconf. Why are you patching generated files? That is never a good idea. > I am now exploring the possibility of making one patch modifying configure.ac, > and another that would be easy to refresh with autoreconf. But before doing so > I would like to hear your advices: isn't this -m64 micromanaging useless and > should I propose Upstream to give full freedom to Autoconf to deal with the > issue? Send a patch upstream and educate them why this is a bad idea. Until they accept it, patch configure.ac and regenerate configure with whatever mechanism upstream uses to regenerate it (sometimes there is an autogen.sh, other times they just use autoreconf). make maintainer-clean (from automake) should be able to clean up properly afterwards. > However, as I do not understand the purpose of -D_FILE_OFFSET_BITS=64, I am > worried it would be breaking maq on 32-bit arches to remove it. How can we > have > a configure file that does the right thing: -m64 only on 64-bit architectures? A couple of docs I found with Google: http://www.suse.de/~aj/linux_lfs.html http://www.delorie.com/gnu/docs/glibc/libc_285.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
