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,
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 gmp.h which fails now completely (it is not
installed,
I have it
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 scripts
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 do some
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 recursive call for build != host: Define
GENERATOR_FILE. Comment. Use CXX_FOR_BUILD,
On Wed, Jan 22, 2014 at 09:21:46PM -0700, Jeff Law wrote:
* Makefile.in (BUILD_CPPFLAGS): Do not use ALL_CPPFLAGS.
* configure.ac recursive call for build != host: Define
GENERATOR_FILE. Comment. Use CXX_FOR_BUILD, CXXFLAGS_FOR_BUILD
and LD_FOR_BUILD too.
*
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 looks
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
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
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
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 Thu, Dec 19, 2013 at 11:50:02AM
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
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 isn't
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
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 gmp.h which fails now completely (it is not
installed,
I have it
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
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 gmp.h which fails now completely (it is not
installed,
I have it in-tree).
Yes, I understand the reason why your setup
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
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 is
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
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 violate this
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?
--
Eric
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 =
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 a
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 violate this
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
-gnatpg
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 passed
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
OK,
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
+++
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
---
.. 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 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 it in
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 get the GCC
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 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 the
On Tue, Dec 03, 2013 at 11:44:46PM -0500, DJ Delorie wrote:
Alan Modra amo...@gmail.com writes:
Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
* configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
build != host.
recursive call for build != host: Clear
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 amo...@gmail.com writes:
Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
* configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
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
Alan Modra amo...@gmail.com writes:
Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
* configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
build != host.
recursive call for build != host: Clear GMPINC. Don't bother
saving CFLAGS.
*
On Tue, Dec 03, 2013 at 11:44:46PM -0500, DJ Delorie wrote:
Alan Modra amo...@gmail.com writes:
Bootstrapped etc. powerpc64-linux. OK mainline and 4.8 branch?
* configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for
build != host.
recursive call for build != host: Clear
40 matches
Mail list logo
