On 03/26/14 22:18, Alan Modra wrote:
On Wed, Mar 26, 2014 at 09:43:08PM +, Maciej W. Rozycki wrote:
Alan,
On Tue, 17 Dec 2013, Alan Modra wrote:
On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
the reason for this is overwriting GMPINC for the auto-build generation, becaus
On Wed, Mar 26, 2014 at 09:43:08PM +, Maciej W. Rozycki wrote:
> Alan,
>
> On Tue, 17 Dec 2013, Alan Modra wrote:
>
> > On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
> > > the reason for this is overwriting GMPINC for the auto-build generation,
> > > because
> > > many test
Alan,
On Tue, 17 Dec 2013, Alan Modra wrote:
> On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
> > the reason for this is overwriting GMPINC for the auto-build generation,
> > because
> > many test scripts include which fails now completely (it is not
> > installed,
> > I have
On Fri, Jan 24, 2014 at 10:34:10AM -0700, Jeff Law wrote:
> >Of course, then your question becomes, why exclude CPPFLAGS? (And if
> >CPPFLAGS needs to be excluded here, then I should have just used
> >CPPFLAGS=-DGENERATOR_FILE for the recursive configure call..) I'm not
> >sure now, I'll have to
On 01/23/14 16:02, Alan Modra wrote:
On Wed, Jan 22, 2014 at 09:21:46PM -0700, Jeff Law wrote:
* Makefile.in (BUILD_CPPFLAGS): Do not use ALL_CPPFLAGS.
* configure.ac : Define
GENERATOR_FILE. Comment. Use CXX_FOR_BUILD, CXXFLAGS_FOR_BUILD
and LD_FOR_BUILD too.
On Wed, Jan 22, 2014 at 09:21:46PM -0700, Jeff Law wrote:
> > * Makefile.in (BUILD_CPPFLAGS): Do not use ALL_CPPFLAGS.
> > * configure.ac : Define
> > GENERATOR_FILE. Comment. Use CXX_FOR_BUILD, CXXFLAGS_FOR_BUILD
> > and LD_FOR_BUILD too.
> > * configure: Regenerate.
> The co
On 01/22/14 20:46, Alan Modra wrote:
I was hoping for a reply from someone who could OK the previous patches
submitted. Admittedly, I didn't tick all the boxes (no changelog entry),
so here they are again.
It's been in my stack of patches, others may be shying away from the
insanity that is our
I was hoping for a reply from someone who could OK the previous patches
submitted. Admittedly, I didn't tick all the boxes (no changelog entry),
so here they are again.
The Makefile.in BUILD_CPPFLAGS change is for exactly the same reason
as my 2013-12-05 change. When GMPINC points at an installe
Hi,
it is quite late in P3 now, so how about the attached patch?
This would return to the status quo before your patch, where $GMPINC must be !=
sysroot.
Bernd.
> Date: Tue, 7 Jan 2014 16:45:15 +0100
>
> Hi Alan,
>
>
> This issue is not yet resolved, in the moment this cross-compiler issue l
Hi Alan,
This issue is not yet resolved, in the moment this cross-compiler issue looks
like a regression.
But I have tried your follow-up patches, and they make sense for me:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01544.html
How c
> Date: Fri, 20 Dec 2013 07:57:02 +1030
> From: amo...@gmail.com
> To: bernd.edlin...@hotmail.de
> CC: gcc-patches@gcc.gnu.org; ja...@redhat.com; d...@redhat.com;
> ebotca...@adacore.com
> Subject: Re: Two build != host fixes
>
> On
On Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
> Isn't the actual invocation of the build-g++ also including
> /sysroot_for_host/include
> in that case? Why doesn't this cause problems then?
Yes, and that causes failures too. BUILD_CPPFLAGS is the culprit.
See http://gcc.gnu.org
On Thu, 19 Dec 2013 20:41:43, Alan Modra wrote:
>
> On Wed, Dec 18, 2013 at 02:32:01PM +0100, Bernd Edlinger wrote:
>> I wonder if the GMPINC="" is still necessary, as the actual host g++
>> invocation also has GMP-directories
>> but does not use them because of the -DGENERATOR_FILE.
>
> The issue
On Wed, Dec 18, 2013 at 02:32:01PM +0100, Bernd Edlinger wrote:
> I wonder if the GMPINC="" is still necessary, as the actual host g++
> invocation also has GMP-directories
> but does not use them because of the -DGENERATOR_FILE.
The issue isn't finding gmp.h, it's finding other host headers you
Hi,
On Wed, 18 Dec 2013 09:58:39, Alan Modra wrote:
>
> On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
>> the reason for this is overwriting GMPINC for the auto-build generation,
>> because
>> many test scripts include which fails now completely (it is not
>> installed,
>> I ha
On Tue, Dec 17, 2013 at 01:14:23PM +0100, Bernd Edlinger wrote:
> the reason for this is overwriting GMPINC for the auto-build generation,
> because
> many test scripts include which fails now completely (it is not
> installed,
> I have it in-tree).
Yes, I understand the reason why your setup i
Hi Alan,
just for the records, this is how my cross-build fails:
../gcc-4.9-20131215/configure --prefix=/home/ed/gnu/x/arm-linux-gnueabihf-cross
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
--enable-languages=c,c++ --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --wi
> OK, now it works.
Thanks for confirming, I've installed the patch.
> I wonder if you could add some really good comments in the system.ads
> what's the problem and how to fix it if the No_Implicit_Dynamic_Code
> makes problems like these?
I think that we need to catch the problem earlier, that
Hi Eric,
>
> OK, I think that this compiler is misconfigured, could you try this
>
> Index: gcc-interface/Makefile.in
> ===
> --- gcc-interface/Makefile.in (revision 205918)
> +++ gcc-interface/Makefile.in (working copy)
> @@ -1903,7
> .. then does the second block need hoisting to bracket the two cases with
> host!=build?
This code works fine so I don't think that we really need to do anything.
--
Eric Botcazou
On 12 Dec 2013, at 17:21, Eric Botcazou wrote:
>> With your blanket change to gnattools/Makefile, isn't it also reasonable to
>> apply the following?
>>
>> diff --git a/gcc/ada/gcc-interface/Make-lang.in
>> b/gcc/ada/gcc-interface/Make-lang.in index cd3676f..241571d 100644
>> --- a/gcc/ada/gcc-i
> With your blanket change to gnattools/Makefile, isn't it also reasonable to
> apply the following?
>
> diff --git a/gcc/ada/gcc-interface/Make-lang.in
> b/gcc/ada/gcc-interface/Make-lang.in index cd3676f..241571d 100644
> --- a/gcc/ada/gcc-interface/Make-lang.in
> +++ b/gcc/ada/gcc-interface/Mak
On 12 Dec 2013, at 15:23, Eric Botcazou wrote:
>> Darwin doesn't have gettext in libSystem, I build it as a convenience
>> library, but it still needs to refer to a system framework. For this to
>> link the gnattools I need:
>>
>> LDFLAGS="-L/path/to/my/convenience/lib -framework CoreFoundation"
> Darwin doesn't have gettext in libSystem, I build it as a convenience
> library, but it still needs to refer to a system framework. For this to
> link the gnattools I need:
>
> LDFLAGS="-L/path/to/my/convenience/lib -framework CoreFoundation"
OK, I'll add $(LDFLAGS). It was actually already pa
> arm-linux-gnueabihf-gcc -c -I./
> -I/home/ed/gnu/x/arm-linux-gnueabihf-linux64/lib/gcc/arm-linux-gnueabihf/4.
> 9.0/adalib/../adainclude
> -I/home/ed/gnu/x/arm-linux-gnueabihf-linux64/lib/gcc/arm-linux-gnueabihf/4.
> 9.0/adalib/ -I. -I/home/ed/gnu/x/gcc-4.9-20131208/gcc/ada -g -O2 -W -Wall
> -gna
>
>> your patch looks quite nice, (maybe s/host_alias= @host_alias@/host_alias =
>> @host_alias@/)
>
> Thanks for spotting it, now fixed.
>
>> but I have to make a few more patches, to get it working:
>>
>>
>> error: "system.ads" has restriction No_Implicit_Dynamic_Code
>> error: but the following
Hi Eric,
On 12 Dec 2013, at 12:34, Eric Botcazou wrote:
>> using your patch + the mod I made for LDFLAGS.
>
> In gcc-interface/Makefile.in? I wasn't sure if it was really needed.
>
> Out of curiosity, what do you set LDFLAGS to exactly?
Darwin doesn't have gettext in libSystem, I build it as
> using your patch + the mod I made for LDFLAGS.
In gcc-interface/Makefile.in? I wasn't sure if it was really needed.
Out of curiosity, what do you set LDFLAGS to exactly?
> I built x86_64-darwin12 X powerpc-darwin9 [build = x86_64-darwin12]
> and then a native X powerpc-darwin9 [build = x86_6
Hi Eric,
On 12 Dec 2013, at 12:11, Bernd Edlinger wrote:
>>
>>> I have some more fixes for Ada cross-builds that Eric commented on but need
>>> a little more work - will try to re-test this evening and re-post tomorrow.
>>
>> It's also PR ada/55946. Would mind trying the attached patch?
>>
>>
> your patch looks quite nice, (maybe s/host_alias= @host_alias@/host_alias =
> @host_alias@/)
Thanks for spotting it, now fixed.
> but I have to make a few more patches, to get it working:
>
>
> error: "system.ads" has restriction No_Implicit_Dynamic_Code
> error: but the following files viola
>
>> I have some more fixes for Ada cross-builds that Eric commented on but need
>> a little more work - will try to re-test this evening and re-post tomorrow.
>
> It's also PR ada/55946. Would mind trying the attached patch?
>
> --
> Eric Botcazou
Hi Eric,
your patch looks quite nice, (maybe s/
On Wed, Dec 11, 2013 at 02:11:49PM +0100, Bernd Edlinger wrote:
> We need the auto-build only to build something that translates .md files to
> .c,
> so I would'nt care about GMP, but some other things, like the right prototype
> for
> printf make a difference.
Right, but when you get some of th
> I have some more fixes for Ada cross-builds that Eric commented on but need
> a little more work - will try to re-test this evening and re-post tomorrow.
It's also PR ada/55946. Would mind trying the attached patch?
--
Eric BotcazouIndex: gnattools/Makefile.in
On 11 Dec 2013, at 13:11, Bernd Edlinger wrote:
> I did not have this one.
> What is it good for?
>
>> # Actual name to use when installing a native compiler.
>> GCC_INSTALL_NAME := $(shell echo gcc|sed '$(program_transform_name)')
>> diff --git a/gcc/ada/gcc-interface/Make-lang.in
>> b/gcc/ada/
On Wed, 11 Dec 2013 23:11:46, Alan Modra wrote:
>
> On Wed, Dec 11, 2013 at 12:10:04PM +0100, Bernd Edlinger wrote:
>> Hi,
>>
>> I'm having problems with that patch.
>
> Sorry to hear that.
>
Never mind.
I have similar patches, but I did not
>> I try to start at X86_64-linux-gnu, and I want to g
On Wed, Dec 11, 2013 at 12:10:04PM +0100, Bernd Edlinger wrote:
> Hi,
>
> I'm having problems with that patch.
Sorry to hear that.
> I try to start at X86_64-linux-gnu, and I want to get the GCC running on
> arm-linux-gnueabihf.
> I grabbed system headers and libraries from the target and put i
Hi,
I'm having problems with that patch.
I try to start at X86_64-linux-gnu, and I want to get the GCC running on
arm-linux-gnueabihf.
I grabbed system headers and libraries from the target and put it in the prefix
path.
In the first step I do
../gcc-4.9-20131208/configure --prefix=/home/ed/g
On Mon, Dec 09, 2013 at 03:04:44PM +1030, Alan Modra wrote:
> On Tue, Dec 03, 2013 at 11:44:46PM -0500, DJ Delorie wrote:
> > Alan Modra writes:
> > > Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
> > >
> > > * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
> > > bu
On Tue, Dec 03, 2013 at 11:44:46PM -0500, DJ Delorie wrote:
> Alan Modra writes:
> > Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
> >
> > * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
> > build != host.
> > : Clear GMPINC. Don't bother
> > saving CF
On Wed, Dec 04, 2013 at 04:36:58PM +1030, Alan Modra wrote:
> Maybe we should use most of BUILD_EXPORTS in the top level
> Makefile.in? What can go wrong with that? :)
I had a look at this, as it's easy to do, but I didn't find any
significant bug to justify such a change in stage3. So I've comm
On Tue, Dec 03, 2013 at 11:44:46PM -0500, DJ Delorie wrote:
> Alan Modra writes:
> > Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
> >
> > * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
> > build != host.
> > : Clear GMPINC. Don't bother
> > saving CF
Alan Modra writes:
> Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
>
> * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
> build != host.
> : Clear GMPINC. Don't bother
> saving CFLAGS.
> * configure: Regenerate.
Ok for mainline, up to the
42 matches
Mail list logo
