This is the mail archive of the
mailing list for the GCC project.
Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers
- From: R0b0t1 <r030t1 at gmail dot com>
- To: Freddie Chopin <freddie_chopin at op dot pl>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 18 Aug 2017 11:17:10 -0500
- Subject: Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers
- Authentication-results: sourceware.org; auth=none
- References: <CAAD4mYh++6hLNi9_0ksmAL3kdoEiAZ6mT6+EH4RLggTqEY=1MQ@mail.gmail.com> <CAAD4mYh5Uc0RFOKKHd=ihFW1hi94fX2mQ8BNn=-DJt7trdnh_w@mail.gmail.com> <firstname.lastname@example.org> <email@example.com>
On Fri, Aug 18, 2017 at 1:09 AM, Freddie Chopin <firstname.lastname@example.org> wrote:
> On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote:
>> On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 <email@example.com> wrote:
>> > When compiling libssp, ssp.c, function __guard_setup:
>> > O_RDONLY is undeclared (ssp.c:93:34),
>> > ssize_t is an unknown type name (ssp.c:96:7), and
>> > size_t is an unknown type name (ssp.c:113:25).
>> > ../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX
>> > --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard
>> > --with-mode=thumb --enable-multilib --enable-interwork
>> > --enable-languages=c,c++ --with-system-zlib --with-newlib
>> > --disable-shared --disable-nls --with-gnu-as --with-gnu-ld
>> > A bootstrap C compiler is generated properly when passing --
>> > without-headers.
>> > I can provide more details and command output. Recently I was able
>> > to
>> > get 6.3.0 as close to working with Newlib 2.5 as I can tell, so
>> > this
>> > is not extremely urgent. Unfortunately I may have other questions
>> > about earlier GCC versions.
>> I attempted to reproduce my build of GCC 6.3 and it's no longer
>> working. Both builds on Kubuntu 17.04.
>> I'm kind of lost. Should I be filing bugs?
>> > Any suggestions related to generating cross toolchains,
>> > specifically
>> > generating a toolchain close to the one found at
>> > https://developer.arm.com/open-source/gnu-toolchain/gnu-rm, would
>> > be
>> > extremely helpful. Any help provided will be used to better support
>> > for generating toolchains with the crossdev project.
>> > I am very confused and what I want to do seems to be poorly
>> > documented.
>> > Thanks in advance,
>> > R0b0t1.
> Here you may find a complete script which builds the most recent
> versions of the toolchain for arm-none-eabi. If you browse git history
> you will also find a version for GCC 6.3.
On Fri, Aug 18, 2017 at 1:53 AM, Freddie Chopin <firstname.lastname@example.org> wrote:
> I forgot to say, that the procedure and resulting toolchain is closely
> modeled after the one provided by ARM on:
> It just has couple of tweaks like slightly different options for
> newlib, completely disabled C++ exceptions and uses the most recent
> versions of components.
Thank you! I was able to use that script to produce a working
toolchain. I had successfully produced toolchains before, but the code
would not execute on device. Just to check, this is actually an
arm-none-eabi toolchain? I looked over the compilation flags and it
looks like it supports all Cortex-M processor features like such a
toolchain should. Most instructions I could find seemed to build a
more restricted toolchain.
I have looked at the supporting blog posts and read the documentation
available. I still do not understand why the specific binutils, gcc,
newlib, and gdb configurations were chosen, and why what is ostensibly
the same configuration failed when I tried it Would you please take
the time to document them, or point me towards a place that describes
what I should be looking for and why? I don't mind reading but I do
not know why the choices made are the correct ones and have been
unable to find anywhere that starts to offer any explanation.
I apologize for requesting that you donate your time, but if you feel
inclined you might want to look at the crossdev project. If I
eventually understand your script, or even if I don't, I may be able
to add better embedded target support (embedded targets are already
supported, but I receive build failures). Unfortunately the developers
of my distribution do not seem to have much of a hardware background
and people seem to expect me to contribute code. I am not smart enough
to do this, sir, and would appreciate whatever help you can offer to