How does (avr-)gcc/g++ know of default include directories?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey All!

 

Yesterday evening I built a recent version (7.2) of the avr-gcc toolchain (see this post). I started the day with a quick test, and it can not locate the default include files (e.g. avr/io.h and all that it pulls with it).

 

I tested by actually placing a minimal C++ test program in the bin directory and tried a straight compile:

$ ./avr-gcc -std=c++11 -mmcu=atmega328 -c test.cpp 
test.cpp:1:10: fatal error: avr/io.h: No such file or directory
 #include <avr/io.h>
          ^~~~~~~~~~
compilation terminated.

So, the toolchain sort of "works", but can't get to the include files that should be "built in" for an avr-gcc.

 

Note: I also have Atmels build/distribution of the tool chain installed (gcc version 4.9.2), and performing the same procedure there succeeds. As I recall I only unzipped that package and made PATH point to it and it worked.

 

So, how does a gcc compiler know of its default include directories?

 

I assume it has something to do with the configure-scripts and/or building of the toolchain. The build script I used is a variant of the script here (originally pointed out by El Tangas) - I just set it to not build the Windows tool chains (and after a first run I commented out the downloading of the source tarballs so as not to eat on my metered connection). Sorry, the build script I have and use is somewhat of a mess because of all those comments. I'll clean it up later and post here. But for the time being, I'm primarily looking for a better understanding of how in general the "built in" include paths work in (avr-)gcc.

 

I have a rudimentary to fair knowledge of Autotools and friends, so don't be afraid of using such terminology. I'll ask if I loose you re such matters.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As you say it's part of the configure. It's usually set relative to the bin where the avr-gcc is created.

 

To make what you have work try setting C_INCLUDE_PATH and/or CPLUS_INCLUDE_PATH to the location of the stdio.h at the base of the include tree you have taken from AVR-LibC.

 

Now I thought I could just run a compiler here with -v and show you it but my one says:

C:\SysGCC\avr\bin>avr-gcc -v
Using built-in specs.
Reading specs from c:/sysgcc/avr/bin/../lib/gcc/avr/5.3.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=c:/sysgcc/avr/bin/../libexec/gcc/avr/5.3.0/lto-wrapper.exe
Target: avr
Configured with: ../gcc-5.3.0/configure --target avr --enable-win32-registry=SysGCC-avr-5.3.0 --enable-languages=c,c++ --disable-nls --without-libico
v-prefix --prefix /q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/ --host i686-pc-mingw32 --disable-shared --with-avrlibc=yes
Thread model: single
gcc version 5.3.0 (GCC)

As that doesn't seem to specifically mention an actual location I can only assume that the --with-avrlibc=yes has some implication about where it expects to (relatively) find the avrlibc header tree.

 

EDIT: or maybe not:

 

https://gcc.gnu.org/bugzilla/sho...

 

So that is a configure option that Gerog-Johann added at 4.7 and is about finding lib code - not headers.

Last Edited: Tue. Oct 24, 2017 - 09:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow this looks interesting...

 

https://stackoverflow.com/questi...

 

So:

C:\SysGCC\avr\bin>avr-gcc -print-prog-name=cc1plus
c:/sysgcc/avr/bin/../libexec/gcc/avr/5.3.0/cc1plus.exe

C:\SysGCC\avr\bin>c:/sysgcc/avr/bin/../libexec/gcc/avr/5.3.0/cc1plus.exe -v
ignoring nonexistent directory "/q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/avr/include/c++/5.3.0"
ignoring nonexistent directory "/q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/avr/include/c++/5.3.0/avr"
ignoring nonexistent directory "/q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/avr/include/c++/5.3.0/backward"
ignoring nonexistent directory "/q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/lib/gcc/avr/5.3.0/include"
ignoring nonexistent directory "/q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/lib/gcc/avr/5.3.0/include-fixed"
ignoring nonexistent directory "/q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/avr/sys-include"
ignoring nonexistent directory "/q/gnu/auto/bu-2.25+gcc-5.3.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2-avr/avr/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.

Well, OK, not THAT interesting then! So it seems there are no (available) configured paths. yet:

C:\SysGCC\avr\bin>nano avr.c
ff

C:\SysGCC\avr\bin>type avr.c
#include <avr/io.h>

int main(void) {
}

C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega16 -H avr.c -o avr.elf
. c:\sysgcc\avr\avr\include\avr\io.h
.. c:\sysgcc\avr\avr\include\avr\sfr_defs.h
... c:\sysgcc\avr\avr\include\inttypes.h
.... c:\sysgcc\avr\lib\gcc\avr\5.3.0\include\stdint.h
..... c:\sysgcc\avr\avr\include\stdint.h
.. c:\sysgcc\avr\avr\include\avr\iom16.h
.. c:\sysgcc\avr\avr\include\avr\portpins.h
.. c:\sysgcc\avr\avr\include\avr\common.h
.. c:\sysgcc\avr\avr\include\avr\version.h
.. c:\sysgcc\avr\avr\include\avr\fuse.h
.. c:\sysgcc\avr\avr\include\avr\lock.h

C:\SysGCC\avr\bin>

So somehow it knew to look in ..\avr\include as the base of the system header search ? (for an easy life I have my "test" .c file in the same directory as the avr-gcc.exe executable).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to: http://www.nongnu.org/avr-libc/user-manual/install_tools.html

Everything should be in the same folder, so these 2 lines would be the ones that breaks the tool chain I believe:

PREFIX_LINUX=/omgwtfbbq/linux

PREFIX_LIBC=/omgwtfbbq/libc

 

Change them to the same folder, and I think everything SHOULD be okay.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a way to then get a compiler that has been built from that to reveal what its setting of those things are?

 

EDIT actually googling seems to show the only use of PREFIX_LIBC is in AVR build scripts where it does something like:

PREFIX_LIBC=/omgwtfbbq/libc
echo "Clearing output directories..."
[ $BUILD_LINUX -eq 1 ] && makeDir "$PREFIX_LINUX"
[ $BUILD_WIN32 -eq 1 ] && makeDir "$PREFIX_WIN32"
[ $BUILD_WIN64 -eq 1 ] && makeDir "$PREFIX_WIN64"
[ $BUILD_LIBC -eq 1 ] && makeDir "$PREFIX_LIBC"
# Make AVR-LibC
if [ $BUILD_LIBC -eq 1 ]; then
    echo "Making AVR-LibC..."
    echo "Extracting..."
    bunzip2 -c $NAME_LIBC.tar.bz2 | tar xf -
    mkdir -p $NAME_LIBC/obj-avr
    cd $NAME_LIBC/obj-avr
    confMake "$PREFIX_LIBC" "$OPTS_LIBC" --host=avr --build=`../config.guess`
    cd ../../
fi

So that's just saying where AVR-LibC should be built - it doesn't seem to be involved in "connecting" that to the compiler itself?

Last Edited: Tue. Oct 24, 2017 - 01:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@canbeany: I'm not sure to what exactly you are referring. Could you point me to the precise formulation?

 

As far as directory structure, my build comes out essentially the same as Atmels tool chain. Neither has "everything in the same folder". That would simply not be possible since e.g. a number of different runtime libraries are built, all with the same name (libgcc.a, libgcov.a) but in different directories. 

 

Need to do some other stuff. Will revisit this evening, hopefully.

 

@cliff: I'll have a look.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Other things got in the way, and it's getting late. This will have to wait until another day.

 

I have some ideas, though: The ultimate goal of the script is to cross-build, on a Linux system, an avr-gcc tool chain to run on Windows. Still it starts out with building the toolchain to run on Linux, and there is a note that this is a necessary step. I have a suspicion that this is done solely to have a Linux-hosted toolchain to build avrlibc. It just might be that the build of the Linux-hosted tool chain is built differently and is "crippled" in a way that has sno effect on building avrlibc but has effects when building for a specific "mmcu=" target. I am spotting some differences in the build script..

 

Next stint on this, I'll probably have a look at the details of how the Windows builds are set up, configured and run..

 

I've attached the script in the version I use. Essentially I've done two things:

- Changed the prefixes

- Commented out installation of Cygwin-related stuff and similar (not applicable for a Linux-hosted tool chain), and fetching of sources (after first run with download I have them locally, and don't want to load my metered Internet connection more than necessary).

 

A build (without downloads and without building Windows-hosted tool chains takes about 20 to 25 minutes (Linux Mint 18.2 64-bit on Intel Core i5-3320M 2.6GHz x 2, 8GB RAM and solid state disk).

 

 

Attachment(s): 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

As far as directory structure, my build comes out essentially the same as Atmels tool chain. Neither has "everything in the same folder". That would simply not be possible since e.g. a number of different runtime libraries are built, all with the same name (libgcc.a, libgcov.a) but in different directories. 

 

I read and answer a little too fast for my slow head sometimes.. I was referring to the binaries.

 

But now that I am awake (and without medicationZzZ), don't the the libc page I linked to say everything right on the top?

 

Building and Installing under Linux, FreeBSD, and Others

The default behaviour for most of these tools is to install every thing under the /usr/local directory. In order to keep the AVR tools separate from the base system, it is usually better to install everything into /usr/local/avr. If the /usr/local/avr directory does not exist, you should create it before trying to install anything. You will need root access to install there. If you don't have root access to the system, you can alternatively install in your home directory, for example, in $HOME/local/avr. Where you install is a completely arbitrary decision, but should be consistent for all the tools.

You specify the installation directory by using the –prefix=dir option with the configure script. It is important to install all the AVR tools in the same directory or some of the tools will not work correctly. To ensure consistency and simplify the discussion, we will use $PREFIX to refer to whatever directory you wish to install in. You can set this as an environment variable if you wish as such (using a Bourne-like shell):

$ PREFIX=$HOME/local/avr
$ export PREFIX

Note
Be sure that you have your PATH environment variable set to search the directory you install everything in before you start installing anything. For example, if you use –prefix=$PREFIX, you must have $PREFIX/bin in your exported PATH. As such:
$ PATH=$PATH:$PREFIX/bin
$ export PATH

I built the toolchain from the script you linked to, and at least it compiles a simple program with "io.h" included without errors.

 

If you share your modified script, I think it will be easier to find out what is wrong with your toolchain.

 

Just saw your new post, for a more "proper" linux buildscript take a look at the one in Arch user repo: https://git.archlinux.org/svntogit/community.git/tree/trunk?h=packages/avr-gcc

Last Edited: Tue. Oct 24, 2017 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All tools are in the same directory.

 

And, again: The structure I get is the same as e.g. the Atmel build of the tool chain.

 

To me it seems like there is something not passed to the build of the (Linux-hosted) tool chain that makes it look for AVR-specific include files in ../include/avr (relative to the bin directory).

 

Thank you for the pointer to the Arch script. I will have a look at it (but not today).

 

I also still haven't followed up on Cliffs tips re "asking the compiler about its configuration".

 

I'll be back!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I keep making reading mistakes.. :s Sorry!

It seems GCC defaults to /usr/include

 

To list includes:

a@elite:~$ `avr-gcc -print-prog-name=cc1` -v
ignoring nonexistent directory "/usr/lib/gcc/avr/4.9.2/../../../avr/sys-include"
ignoring nonexistent directory "/usr/lib/gcc/avr/4.9.2/../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/avr/4.9.2/include
 /usr/lib/gcc/avr/4.9.2/include-fixed
End of search list.

 

And to compile with a specific header directory

‘--with-headers=directory’
Look for kernel header files in directory, not /usr/include.
The GNU C Library needs information from the kernel’s header files describing the interface to the kernel. 
The GNU C Library will normally look in /usr/include for them, but if you specify this option, it will look in DIRECTORY instead.

This option is primarily of use on a system where the headers in /usr/include come from an older version of the GNU C Library. 
Conflicts can occasionally happen in this case. You can also use this option if you want to compile the GNU C Library with a newer set of kernel headers than
the ones found in /usr/include.

 

Going to build the toolchain on my elitebook now, will test your modified script, Johan.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For me the easiest configuration is:

 

1) configure all stuff (gcc, binutils, libc) with the same --prefix and avoid --exex-prefix and similar gaga.  I  prefer --prefix in some sandbox (e.g. home) so that there is no need to be root at any time.  Moreover, after install, you can move the stuff (top folder) freely around or just rm it.

 

2) Use in-tree build for GMP, MPFR, MPC and do *not* install them seperately.  In-tree build is simply triggered by running ./contrib/dowload_prerequisites from toplevel GCC source.. No extra configure options needed, gcc configury will autodetect gmp, mpfr, mpc.  That way, you always use host libraries versions as expected ny GCC.  Takes bit more time to build, but no need to hamper with GMP install paths etc.

 

3) Don't configure in source tree (for GCC that isn't even supported).  Always (as in ALWAYS) configure in an empty build directory.  If you got scrap, you can just recursively remove the whole build dir.

 

The procedure is:

 

1) Download sources (gcc, binutils and libc) and run gcc: ./contrib/download_prerequisites and libc: ./bootstrap.

 

2) configure-build-install binutils

 

3) configure-build-install gcc using --prefix from 2)

 

4) add newly installed gcc to PATH. Alternatively, you can run 5) with CC=GCC_INSTALL/bin/avr-gcc  or CC='GCC_BUILD/gcc/xgcc -B GCC_BUILD/gcc'.  In the latter case, you don't even need to install avr-gcc to build libc.

 

5) configure-build-install libc with --prefix from 2). 

 

libc headers will show in GCC_INSTALL/avr/include/avr...

 

 

avrfreaks does not support Opera. Profile inactive.