RE: configuring in-tree gmp/mpfr with none?
Because at some point, no released version worked on intel macs.
Long since passed and can be removed?
Or only do it on those machines??
Granted, the Python-wrapping-build I'm doing ought to work as well on Intel
Macs as anywhere else.
Here is what ends up happening:
#include
#include
int main()
{
signal(SIGPIPE, SIG_IGN);Python does like this
putenv(M4=foo); gmp/configure does like this
system(flex 1.l); gmp/configure does like this
return 0;
}
Without ignoring sigpipe, flex dies in filter_tee_header reading the output of
a failed exec.
Ignoring the signal under a Python wrapper however, it continues on
and deletes the output, causing gmp/configure to fail because it is looking
for the output.
gmp/configure is where the blame really lies, but if gcc configured gmp
normally,
this wouldn't occur. Or, is cpu=none not so abnormal? Just that I hadn't seen
it?
(Everything new and normal is initially new and abnormal, of course.)
- Jay
Date: Thu, 31 Jul 2008 15:53:43 +0200
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]; gcc@gcc.gnu.org
Subject: Re: configuring in-tree gmp/mpfr with none?
Jay wrote:
Andrew, Can you explain more why?
Because at some point, no released version worked on intel macs.
And then gmp/configure runs flex.
And then sometimes?always flex tries to run getenv(M4) || m4.
Yes, Flex uses m4.
gmp/configure probably should not be setting M4
Yes, I think that setting M4=m4-not-needed should be done only for
debugging purposes. Otherwise, GMP should always look for m4 in its
configure script, and set it to a valid value in the makefile.
Paolo
Re: configuring in-tree gmp/mpfr with none?
Jay wrote: Because at some point, no released version worked on intel macs. Long since passed and can be removed? I don't think so, http://gmp.darwinports.com/ shows that it is still a problem with 4.2.2. Besides, GMP's authors say that it is often a stress test for compilers, so using more C and less assembly can be a good thing (GCC's usage of GMP does not include manipulating really really huge numbers). gmp/configure is where the blame really lies, but if gcc configured gmp normally, this wouldn't occur. Or, is cpu=none not so abnormal? Just that I hadn't seen it? It's a GMP-only thing. Given that this is a problem because of Python's apparently broken handling of signals, we cannot do anything about it. Complain with the Python maintainers that they should reset the signals they ignore, before exec-ing another program. Paolo
Re: configuring in-tree gmp/mpfr with none?
On 2008-08-04 13:05:09 +0200, Paolo Bonzini wrote: I don't think so, http://gmp.darwinports.com/ shows that it is still a problem with 4.2.2. This is a commercial and out-of-date web site. You should look at MacPorts instead: http://trac.macports.org/browser/trunk/dports/devel/gmp/Portfile But the --host=none-apple-darwin was initially added on 2004-12-03 (revision 9565), and I don't know if removing it has been tested. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
RE: configuring in-tree gmp/mpfr with none?
Andrew, Can you explain more why? Why I'm asking again now: I have found another problem because of this (besides the reduced ability to share config.cache files). This exacerbates what looks like a minor bug in gmp's configure. Sometimes, depending on build/host/target, gmp's configure sets M4=m4-not-needed. Setting the processor to none is a good way to get it down the not needed path. Though there might be other ways there, granted. And then gmp/configure runs flex. And then sometimes?always flex tries to run getenv(M4) || m4. Flex fails, sometimes creating lex.yy.c, sometimes not. I haven't tracked down this sometimes. When I run build under Python, no lex.yy.c, outside of Python, ok. I still have to dig in further to find out why. When lex.yy.c is not created, configure fails. It is looking for what file is the output. gmp/configure probably should not be setting M4, at least not when it runs flex. But gcc using processor=none doesn't help. I'll follow up with gmp folks. Thanks, - Jay Date: Wed, 18 Jun 2008 06:53:35 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: configuring in-tree gmp/mpfr with none? CC: gcc@gcc.gnu.org On Wed, Jun 18, 2008 at 12:40 AM, Jay wrote: Ah, I didn't realize any C or C++ code could be configured for other than a specific processor but I guess that makes sense -- it is Makefile, config.h, and such that are being modified, not the .o files, and they might be the same across many configurations, like if the compiler command lines and #defines can be the same, like if there is no need to know the size of a pointer or the endianness, etc.. I guess more code should work this way if possible. Thanks Andrew. Well gmp/mpfr are special in that they try to do the same thing as -mcpu=native with their configure script and they have some assembly files. Thanks, Andrew Pinski
Re: configuring in-tree gmp/mpfr with none?
Jay wrote: Andrew, Can you explain more why? Because at some point, no released version worked on intel macs. And then gmp/configure runs flex. And then sometimes?always flex tries to run getenv(M4) || m4. Yes, Flex uses m4. gmp/configure probably should not be setting M4 Yes, I think that setting M4=m4-not-needed should be done only for debugging purposes. Otherwise, GMP should always look for m4 in its configure script, and set it to a valid value in the makefile. Paolo
Re: configuring in-tree gmp/mpfr with none?
On Wed, Jun 18, 2008 at 12:40 AM, Jay [EMAIL PROTECTED] wrote: Ah, I didn't realize any C or C++ code could be configured for other than a specific processor but I guess that makes sense -- it is Makefile, config.h, and such that are being modified, not the .o files, and they might be the same across many configurations, like if the compiler command lines and #defines can be the same, like if there is no need to know the size of a pointer or the endianness, etc.. I guess more code should work this way if possible. Thanks Andrew. Well gmp/mpfr are special in that they try to do the same thing as -mcpu=native with their configure script and they have some assembly files. Thanks, Andrew Pinski
Re: configuring in-tree gmp/mpfr with none?
On Sun, Jun 15, 2008 at 12:49 PM, Jay [EMAIL PROTECTED] wrote:
When gcc configures the in-tree gmp/mpfr, why
does it use --host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}
instead of --host=${host_alias} --target=${target_alias}
This breaks config.cache if used across directories, because the platforms
change.
The reason why it is configured with none is so that it can be
transfered to more computers than your own.
-- Pinski
RE: configuring in-tree gmp/mpfr with none?
[again as plain text]
Ah, I didn't realize any C or C++ code could be configured for other than a
specific processor but I guess that makes sense -- it is Makefile, config.h,
and such that are being modified, not the .o files, and they might be the same
across many configurations, like if the compiler command lines and #defines can
be the same, like if there is no need to know the size of a pointer or the
endianness, etc.. I guess more code should work this way if possible. Thanks
Andrew.
(Obviously a lot of source code is independent of pointer size, endianness, but
I haven't seen such configure processor=none use.).
- Jay
Date: Tue, 17 Jun 2008 13:39:42 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: configuring in-tree gmp/mpfr with none?
CC: gcc@gcc.gnu.org
On Sun, Jun 15, 2008 at 12:49 PM, Jay wrote:
When gcc configures the in-tree gmp/mpfr, why
does it use --host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}
instead of --host=${host_alias} --target=${target_alias}
This breaks config.cache if used across directories, because the platforms
change.
The reason why it is configured with none is so that it can be
transfered to more computers than your own.
-- Pinski
