"CC=../../xgcc -B../../" \
+ "LINKER=$(CXX)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
I think you should rather do
"CC=../../xgcc -B../../" \
+ "CXX=../../g++ -B../../" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
+ "CXXFLAGS=$(CXXFLAGS) $(WARN_CFLAGS)" \
On Sat, 2009-06-27 at 13:51 +0200, Laurent GUERBY wrote:
> On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote:
> > > This was the only va_arg usage, may be we should apply it on trunk too
> > > as the patched version is supposed to work for both C and C++.
> >
> > Yes, but I'm testing a patch
On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote:
> > This was the only va_arg usage, may be we should apply it on trunk too
> > as the patched version is supposed to work for both C and C++.
>
> Yes, but I'm testing a patch for trunk with more changes.
For reference here is my current draf
> This was the only va_arg usage, may be we should apply it on trunk too
> as the patched version is supposed to work for both C and C++.
Yes, but I'm testing a patch for trunk with more changes.
--
Eric Botcazou
On Fri, 2009-06-26 at 12:52 -0700, Ian Lance Taylor wrote:
> Arnaud Charlet writes:
>
> >> Switching gnatbind to generate Ada if there's nothing against
> >> it might be a better solution since stage1 uses the system gnatbind, so
> >> a patch to current gnatbind will not help (unless we push it t
> Interesting. I've been testing my -Wc++-compat patches with full
> bootstraps including Ada, but I just looked at my make log and it does
> indeed appear that -Wc++-compat doesn't make it onto the Ada files.
>
> It seems to be because of this line in ada/gcc-interface/Make-lang.in:
>
> ada-warn
Arnaud Charlet writes:
>> Switching gnatbind to generate Ada if there's nothing against
>> it might be a better solution since stage1 uses the system gnatbind, so
>> a patch to current gnatbind will not help (unless we push it to branches
>> and tell user to install a fairly recent gnatbind first
> Switching gnatbind to generate Ada if there's nothing against
> it might be a better solution since stage1 uses the system gnatbind, so
> a patch to current gnatbind will not help (unless we push it to branches
> and tell user to install a fairly recent gnatbind first).
This does create a bootst
On Fri, 2009-06-26 at 14:07 -0400, Robert Dewar wrote:
> Ian Lance Taylor wrote:
>
> > gnatbind -C appears to be used when bootstrapping gcc to generate .c
> > files. With --enable-build-with-cxx, those .c files will be compiled
> > with a C++ compiler. The symbols emitted by that compilation ne
Ian Lance Taylor wrote:
gnatbind -C appears to be used when bootstrapping gcc to generate .c
files. With --enable-build-with-cxx, those .c files will be compiled
with a C++ compiler. The symbols emitted by that compilation need to be
linkable with the symbols emitted when compiling Ada code, s
Robert Dewar writes:
> Ian Lance Taylor wrote:
>
>> I think the function to change is Gen_Output_File_C in bindgen.adb.
>
> I don't really see any urgency for this change, yes gnatbind has
> the option to generate C, but it is not the normal path, and only
> of use in unusual circumstances, so I
> I don't really see any urgency for this change, yes gnatbind has
> the option to generate C, but it is not the normal path, and only
> of use in unusual circumstances, so I don't really see the need
> for this output to be C++ compatible. The documentation doesn't
> claim this after all.
We're t
Ian Lance Taylor wrote:
I think the function to change is Gen_Output_File_C in bindgen.adb.
I don't really see any urgency for this change, yes gnatbind has
the option to generate C, but it is not the normal path, and only
of use in unusual circumstances, so I don't really see the need
for thi
> I don't really know how the Ada compiler works, but it looks like this
> code is generated by the gnatbind program. I bet it would work if
> gnatbind -C emitted this at the start of the output:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> and emitted this at the end:
>
> #ifdef __cplusp
Laurent GUERBY writes:
> Next issue is that gnat1 link fails on many missing symbols:
>
> ada/b_gnat1.o: In function `adainit()':
> ada/b_gnat1.c:287: undefined reference to `system__soft_links___elabb()'
> ada/b_gnat1.c:291: undefined reference to
> `system__secondary_stack___elabb()'
>
> a
> > What is the way forward: fixing in some way the Ada Makefile? Or doing
> > search and replace in case of keyword/identifier conflict? If
> > search/replace, do AdaCore people have an opinion on the best way
> > to proceed to avoid maintenance issues in the various trees? (eg: commit
> > of thos
Laurent GUERBY writes:
> What is the way forward: fixing in some way the Ada Makefile? Or doing
> search and replace in case of keyword/identifier conflict? If
> search/replace, do AdaCore people have an opinion on the best way
> to proceed to avoid maintenance issues in the various trees? (eg: c
On Thu, 2009-06-25 at 15:28 -0700, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
> >> I guess this has to do with reserved word conflict on "new":
> >>
> >> <<
> >> tree
> >> substitute_in_type (tree t, tree f, tree r)
> >> {
> >> tree new;
>
> >>
> >> Do you have some way to deal wi
Laurent GUERBY writes:
> Wanting to test Ada on the branch, after checkout I did on x86_64-linux:
>
> ../gcc/configure --enable-languages=c,c++,ada --enable-__cxa_atexit
> --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1/
> --with-gmp=/opt/cfarm/gmp-4.2.4/ --prefix=/n/16/gu
Richard Guenther writes:
>> I guess this has to do with reserved word conflict on "new":
>>
>> <<
>> tree
>> substitute_in_type (tree t, tree f, tree r)
>> {
>> tree new;
>>
>> Do you have some way to deal with this?
>
> Use a non-reserved identifier. I guess on trunk Ada doesn't build
> w
On Thu, Jun 25, 2009 at 11:50 PM, Laurent GUERBY wrote:
> On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
>> I am pleased to report that if you configure gcc with
>> --enable-build-with-cxx, which causes the core compiler to be built
>> using a C++ compiler, a bootstrap on x86_64-unknown
On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
>
> I would like to encourage pe
22 matches
Mail list logo
