On 9 February 2012 08:39, Jean-Pierre Flori <jpfl...@gmail.com> wrote:
> About the SAGE64 stuff, right now when the option is tested it > basically sets the different C??FLAGS to -m64 -g -O2 > As you pointed above I guess the -m64 forces gcc to produce 64 bits > binaries even though the default is 32 bits, so I'm fine with that. > I guess that the -g -O2 flags are set because that's what autoconf > magically chooses on a "standard" system when the C??FLAGS are empty. > Is everybody happy with that ? > I mean that if at some point autoconf decides that different flags > should be used, we will get different flags depending on whether > SAGE64 is set or not. > No, one what would do in this case is ./configure CC="gcc -m64" I was told by the autoconf developers this is the preffered way of handing 64-bit build in all cases. In 95% of cases, added -m64 to CFLAGS works, but there was the odd package (Pynac and Numpy) where this did not. http://trac.sagemath.org/sage_trac/ticket/7861 http://trac.sagemath.org/sage_trac/ticket/8086 When I asked on the autoconf list, I was told how it should be done. I've never bothered changing other packages, as the old way works, but it is sub-optimal. I think the issue has been that whilst adding -m64 causes gcc to compiler 64-bit objects, sometimes this tries to link to 32-bit system libraries. Of course, this will probably never happen... and getting the default > flags would slow the building time of Sage. > > -O2 ia not to my knowledge added universally. I don't think every single .spkg is identical in this respect. Due to various gcc bugs, or bugs in Sage, -O2 does not always work. It's not entirely clear to me how it would be best to handle complier flags if we used autoconf to generate a top-level configure script, since many of the packages have used autoconf to generate their own configure scripts. That in itself is not a problem as many large software packages (for example gcc), would have multiple "configure" scripts. But it might be an issue with Sage. As I said, I think using autoconf would be good for users, as most will have come across this build process many times. I'm not so convinced it would be good for developers though, as I think it would be quite a bit of work to do it *properly*. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org