Arch Linux User Repository

The isl source has been shut down (https://groups.google.com/g/isl-development/c/JGaMo2VUu_8?pli=1), so the package doesn't build anymore. Seems to work fine using libisl.sourceforge.io. Same with stage1.

Greetings schnedan:

There is C++ support on the compiler (see line 65 of this PKGBUILD). However, libstdc++ is not built for two simple reason: it is too large for MSP430 targets and it needs proper libc support. This means that you can use all of the C++ language features supported by GCC, but you can not use C++ Standard Library features (e.g. templates and classes are good, things like std::vector<> are not). Remember that you are in a freestanding environment, so there is no operating system to help you with dynamic allocations so you will need to provide your own allocator, among other things.

You can use C++ (and link C++ code with msp430-elf-g++ instead of msp430-elf-gcc), but you can not link the C++ standard library as this is not built. The sheer size of the standard C++ library is one of the things that the Wiring environment attempt to address. Besides providing a hardware abstraction layer, Wiring also provides a makeshift C++ library tailored at embedded systems. This C++ library, however is not compatible in any way or form with the one dictated by ISO/IEC 14882, and does not provide its functionality.

You may try to enable building the C++ standard library by changing the PKGBUILD in line 76 to:

make all-gcc all-target-libgcc all-target-libstdc++-v3

Then 88 line to:

make DESTDIR="${pkgdir}" install-gcc install-target-libgcc install-target-libstdc++-v3

Please note that this is not guaranteed to work, and if it does, the C++ library will be too large to fit in an MSP430 anyway. You may also note that all other baremetal toolchains in Arch Linux enable C++ support in the compiler but do not enable the C++ standard library.

Cheers, Orlando.

Hi,

• multilib was not active (default on fresh install as it seems)
• lib32-zlib installed manually (seems no dependency for msp430-elf-gcc or its dependencies)

so far now it works like I know it...

Final question: why there is only a libc and no libc++/libstdc++ ? -rw-r--r-- 2 root root 7844402 23. Jan 15:54 libc.a in /usr/msp430-elf/lib

This was why I tried an other fresh install in the VM as my C++ SW does not link after compile (error is about the missing lib), while the same Project as C-Code does... But I Want C++ working

Greetings,

My apologies, I got the file name wrong. The proper one is config.log

You will find a couple of them in your build directory:

$ find . -iname "config.log" ./libcpp/config.log ./intl/config.log ./lto-plugin/config.log ./libiberty/config.log ./libbacktrace/config.log ./libdecnumber/config.log ./build-x86_64-pc-linux-gnu/libcpp/config.log ./build-x86_64-pc-linux-gnu/libiberty/config.log ./build-x86_64-pc-linux-gnu/fixincludes/config.log ./gcc/config.log ./msp430-elf/libgcc/config.log ./msp430-elf/430/libgcc/config.log ./msp430-elf/large/libgcc/config.log ./isl/config.log ./config.log ./fixincludes/config.log

These are created as the configure script runs. I am mainly interested in the log for the configure script that fails. It should be somewhere in:

/tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build/32/zlib

Now looking at the output of your configure script, it looks like gcc is trying to build its own internal zlib instead of using the system's. Also, it looks like you have the multilib repository enabled. I am not sure whether this is the case though. When I build this package, it does not attempt to build zlib alongside it. If this is the case, please make sure you have the lib32-zlib package installed and try to build again.

Cheers, Orlando.

PS. A few more notes, it looks like you are attempting to install msp430-elf-gcc and your AUR helper script goes on and fetch msp430-elf-gcc-stage1 as part of the process. Do you have msp430-elf-binutils installed already? If not, install that first. You should really build each portion of the toolchain separately, as your AUR helper script may get confused with what to pull in. The build order is in the msp430-elf-binutils package.

hi,

thanks for the answer.

cannot find any file named configure.log... not in /tmp/yaourt-tmp-danny/, not anywhere else on the system...

started with yaourt -S msp430-elf-gcc

the process then fails when it tries to build msp430-elf-gcc-stage1

see here most of the console output (all cached lines...) https://ghostbin.com/paste/6jbew

Greetings,

@schnedan: I am unable to reproduce your issue in a fully up to date system. Can you please provide the configure.log file to examine the issue [1]? There seems to be something missing in your system to build this particular PKGBUILD.

Cheers, Orlando.

[1] Please use a paste service such as https://ghostbin.com instead of putting its contents here.

current package seems to have a broken build I here use a clean arch (new install in a VM)

after executing yaourt -S msp430-elf-gcc the process started as normal... until

Running configure in multilib subdirs 32 pwd: /tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build/zlib Running configure in multilib subdir 32 pwd: /tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build mkdir 32 configure: creating cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... msp430-unknown-elf checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for x86_64-pc-linux-gnu-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc -m32 checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc -m32 accepts -g... yes checking for x86_64-pc-linux-gnu-gcc -m32 option to accept ISO C89... unsupported checking for style of include used by make... GNU checking dependency style of x86_64-pc-linux-gnu-gcc -m32... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by x86_64-pc-linux-gnu-gcc -m32... ld -m elf_x86_64 checking if the linker (ld -m elf_x86_64) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... nm checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for ld -m elf_x86_64 option to reload object files... -r checking for x86_64-pc-linux-gnu-objdump... objdump checking how to recognize dependent libraries... pass_all checking for x86_64-pc-linux-gnu-ar... ar checking for x86_64-pc-linux-gnu-strip... strip checking for x86_64-pc-linux-gnu-ranlib... ranlib checking command to parse nm output from x86_64-pc-linux-gnu-gcc -m32 object... failed checking how to run the C preprocessor... /lib/cpp configure: error: in /tmp/yaourt-tmp-danny/aur-msp430-elf-gcc-stage1/src/gcc-7.2.0/gcc-build/32/zlib': configure: error: C preprocessor "/lib/cpp" fails sanity check Seeconfig.log' for more details. make: *** [Makefile:9074: configure-zlib] Fehler 1 ==> FEHLER: Ein Fehler geschah in build(). Breche ab... ==> FEHLER:Makepkg konnte msp430-elf-gcc-stage1 nicht erstellen. ==> Erstellen von msp430-elf-gcc-stage1 neu starten?[j/N] ==> ----------------------------------------------------- ==> n ==> Erstellen von msp430-elf-newlib neu starten?[j/N] ==> ------------------------------------------------- ==> n ==> WARNUNG:Vor dem Fehlschlag wurden Abhängigkeiten installiert

its reproduceable on another vm as well...

can you please verify and supply how to circumstance this behaviour?

Greetings promach, The msp430-elf-* packages utilize upstream sources to build the full toolchain. This is, in fact, what TI and their partners do for their msp430-gcc-opensource release. However, we utilize newer versions of the upstream software, and every once in a while we backport some patches (critical bugfixes and updating the microcontroller list across binutils and gcc) to ensure good functionality. The linker scripts and header files are exactly the same as TI's offering. As for the OpenMSP430 project, their documentation claims full compatibility with TI's core. As such, I do not see why these packages would not generate code that is compatible with that project. Please note that you may need to provide your own linker script and header files. Cheers, Orlando.

Is this based on http://www.ti.com/tool/msp430-gcc-opensource ? Will this AUR package support https://github.com/olgirard/openmsp430 ?

It would seem that I'll need to use to old toolchain at least for some of my most constrained projects, until this is fully solved. I actually have one that barely fits, with just 40-50B left :-) However, it's good info and I'll definitely come back and do some digging. Thanks!