This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: configuring in-tree gmp/mpfr with "none"?
- From: Jay <jayk123 at hotmail dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Thu, 31 Jul 2008 10:59:43 +0000
- Subject: RE: configuring in-tree gmp/mpfr with "none"?
- References: <BAY139-W162C29DAF463FFF6ABB94FE6AE0@phx.gbl> <de8d50360806171039g13d89b36necbc8a67b853e278@mail.gmail.com> <BAY139-W155015ADB5180EDEAB8B9CE6AB0@phx.gbl> <de8d50360806180353x64578a63y20508f5841efd1f@mail.gmail.com>
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: pinskia@gmail.com
> To: jayk123@hotmail.com
> 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