Usage of relative paths when building toolchain

[aentinger]

Hi 👋
Thank you for creating this docker container to build an up-to-date AVR toolchain. I've got one question though: Running your toolchain in combination with a cmake based project I run into the issue that instead of avr-as the host as is invoked. Investigating I've found hard-coded paths in your compilers configuration:

$ avr-g++ -v
Using built-in specs.
Reading specs from /opt/avr-gcc/avr-gcc/bin/../lib/gcc/avr/9.1.0/device-specs/specs-avr2
COLLECT_GCC=avr-g++
COLLECT_LTO_WRAPPER=/opt/avr-gcc/avr-gcc/bin/../libexec/gcc/avr/9.1.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/work/avr-gcc/avr-gcc/ --with-ld=/work/avr-gcc/avr-binutils/bin/avr-ld --with-as=/work/avr-gcc/avr-binutils/bin/avr-as --enable-languages=c,c++ --with-dwarf2 --disable-nls --disable-libssp --disable-shared --disable-threads --disable-libgomp --disable-bootstrap
Thread model: single
gcc version 9.1.0 (GCC) 

By creating a symbolic link at /work/avr-gcc/avr-binutils/bin/avr-as to the actual location of avr-as I can migitate this problem. However, this kind of fix is not really to my taste. Can you remove the hard-coded paths and rebuild the toolchain with relative paths instead? (PS: I've already exhausted alternative options such as exporting the location to PATH and providing symlinks within /usr/local/bin).

[salkinium]

and rebuild the toolchain with relative paths instead?

This would be my preferred solution too, I just couldn't figure out how to do it and gave up!
I then simply copied the toolchain into the same path in out CI docker container, which works, but is a super ugly solution.

If you know how to tell the build system to build with relative paths, I would be very thankful too ;-P

[aentinger]

I've played a bit around with the configuration but have not manage to obtain satisfactory results. In theory it should suffice to do the following replacement:

-  --with-ld=${root}/${INSTALL}/avr-binutils/bin/avr-ld \
-  --with-as=${root}/${INSTALL}/avr-binutils/bin/avr-as \
+  --with-ld=../../../avr-gcc/avr-binutils/bin/avr-ld \
+  --with-as=../../../avr-gcc/avr-binutils/bin/avr-as \

but alas

configure: error: cannot execute: ../../../avr-gcc/avr-binutils/bin/avr-ld: check --with-ld or env. var. DEFAULT_LINKER.

[salkinium]

Yep, that's what I encountered too 😢.

[salkinium]

Hm, maybe the path needs to be relative to whatever binary is calling that (gcc?)? So maybe just avr-ld is enough?

[aentinger]

I agree with you. Running it only with --with-ld=avr-ld and --with-as=avr-as still doesn't do the trick. All the more interesting, that both avr-ld and avr-as are present in $PATH 😕

[rleh]

Since #3 we now build avr-gcc in /opt instead of /work.

So this issue should now be fixed (for everybody who installs it to /opt)?

$ avr-gcc -v
Using built-in specs.
Reading specs from /opt/avr-gcc/avr-gcc/lib/gcc/avr/10.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/opt/avr-gcc/avr-gcc/libexec/gcc/avr/10.2.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/opt/avr-gcc/avr-gcc/ --with-ld=/opt/avr-gcc/avr-binutils/bin/avr-ld --with-as=/opt/avr-gcc/avr-binutils/bin/avr-as --enable-languages=c,c++ --with-dwarf2 --disable-nls --disable-libssp --disable-shared --disable-threads --disable-libgomp --disable-bootstrap
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)

[salkinium]

I mean is there any reason for not installing in /opt? I'm closing this.

[rleh]

Someone might want to install more than one version simultaneously. But this should not happen often.