Arch Linux User Repository

Greetings Gero,

So it looks like the patches are indeed broken. I compiled gcc from git with the patches applied, and it tries to look for the file using the current working directory as the base:

[pid 8520] openat(AT_FDCWD, "msp430-elf-gcc/msp430-elf/include/devices/devices.csv", O_RDONLY) = -1 ENOENT (No such file or directory)

Initially I thought it may have been a sysroot issue, since TI's binary toolchain wasn't configured that way:

Configured with: ../../gcc/configure --target=msp430-elf --enable-languages=c,c++ --disable-nls --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --enable-target-optspace --enable-newlib-nano-formatted-io --with-pkgversion='Mitto Systems Limited - msp430-gcc 7.3.2.154'

Anyway, as previously mentioned, I am not sure overriding system wide configuration is a good idea. It should be up to the administrator to do that. I can provide an install file warning of the issue alongside the PKGBUILD for users of the binary toolchain while the bug is active though.

Cheers,

Orlando.

P.S.: There is another reason that I am hesitant to modify system wide settings. The msp430-elf-gcc-bin package is actually a duplicate of mspgcc-ti in the AUR. The former package adds this one as an optdepends, something that has caused issues before. The latter ships the contents of this package but has the same issue. The toolchain can't find the devices.csv file either, needing a similar fix. I am afraid that people will install this package alongside the mspgcc-ti package by mistake and by me shipping an override on MSP430_GCC_INCLUDE_DIR throw something off, which also makes me hesitant of even adding a notice. To be honest, I think the maintainer of msp430-elf-gcc-elf should fix this on their end.

Hello Orlando,

unfortunately these patches are very bad and do not work. As you can see "msp430-elf/include/devices" is relative so it will never find it. I tried almost all places but it did not work. The only solution is MSP430_GCC_INCLUDE_DIR

Gero

Greetings gmueller,

Thank you for reporting this. The issue here is that the PKGBUILD actually installs the devices.csv file the the incorrect directory. A closer look at the patches submitted to the GCC mailing list reveals that the directory the compiler will look at is msp430-elf/include/devices from the toolchain installation directory if it can not find the MSP430_GCC_INCLUDE_DIR environment variable [1]. Although these patches are yet to make it to the FSF source tree [2][3], I am guessing that they are available in TI's binary distribution. Please try the modified PKGBUILD. You shouldn't need to export that variable anymore.

With that said, I am not sure that overriding system wide configuration is a good idea. There was a discussion in the mspdebug comment section about this though that one revolved around udev rules [4].

In any case, let me if this change works. I do not test TI's binary toolchain against this package.

Cheers, Orlando.

[1] https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01676.html

[2] https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01362.html

[3] https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/config/msp430;h=2e52cbb5180d2d04c1204c212b087716413bebe0;hb=HEAD

[4] https://aur.archlinux.org/packages/mspdebug/

edit: formatting is hard.

Hi!

Could you add a /etc/profile/msp430.sh with "export MSP430_GCC_INCLUDE_DIR=/usr/msp430-elf/include" ? That way, the devices.csv is found automagically.

Thanks Gero

Greetings,

I have decided that it is against the interest of the community as a whole to not include the device description files in this package and to have a separate packages potentially causing any confusion. As such, I have included the device description files in this PKGBUILD to be installed as well as updated the package's description to explicitly state that it includes the device description files.

I apologize for the incident.

Cheers,

Orlando.

Greetings,

Your upstream url for this package is even pointing to TI's version of the compiler.

The upstream URL for this package is TI's sources, as they are the ones who provide the "Header files and linker scripts for MSP430 microcontrollers". The other sources in the msp430-elf toolchain are from upstream: the FSF releases. They link to their respective upstream providers (FSF sites), not TI's.

It sounds like you didn't do enough testing if your package never supported the officially sanctioned GCC toolchain.

Official support for MSP430 in gcc/binutils/gdb is ultimately handled by upstream. Upstream is not TI, upstream is the FSF. At any time the FSF may decide to remove support for it. DJ Delorie, one of the maintainers in binutils-gdb, gcc, and newlib for the MSP430 backend recently stepped down. Only Nick Clifton and I believe Jozef Lawrynowicz remain as active maintainers. If those two step down and nobody steps up the the FSF backend for the MSP430 will be removed.

There was unofficial support before TI and Red Hat partnered to provide the port, but that was never added to upstream sources because of copyright assignment issues, which the FSF is very stringent on. See the old gcc-msp430 and related packages that are hanging around the AUR which are based around the old toolchain that Peter Bigot maintained alongside a few contributors in SourceForge.

Incorrect, there are as far as I can tell no other versions of TI's GCC compiler in community, or AUR for that matter.

I was talking about this [1] in specific, since that is provided by packages in Community. Also, as a matter of fact, there are other packages in the AUR that provide support for the MSP430 microcontroller: the aforementioned gcc-msp430 ones which are based around gcc 4.6 and is no longer maintained [2, 3, 4, 5, 6].

In fact, now that I look at what is here, the msp430-elf-gcc-bin package should actually be merged with mspgcc-ti [7]. It is actually the same thing. The one in [7] was submitted first, and the proper move here was to flag that one out of date instead of creating a new one. Feel free to submit the merge request.

Cheers,

Orlando.

[1] https://aur.archlinux.org/packages/gcc-arm-none-eabi-bin/

[2] https://aur.archlinux.org/packages/gcc-msp430/

[3] https://aur.archlinux.org/packages/binutils-msp430/

[4] https://aur.archlinux.org/packages/msp430-gdb/

[5] https://aur.archlinux.org/packages/msp430-libc/

[6] https://aur.archlinux.org/packages/msp430mcu/

[7] https://aur.archlinux.org/packages/mspgcc-ti/

If we are going to go there, the defacto toolchain for MSP430 is the proprietary one provided by TI in Code Composer Studio. The linker scripts utilized by that toolchain are not compatible with GCC/LD and they use different header files as well. The GCC/Binutils effort was something that came out from having cheap development boards (the launchpad series) and no tools that could be freely distributed like the AVR/Arduino stack. Take from that what you will.

That's being pedantic, you know I meant MSP430-GCC-OPENSOURCE which is as officially supported as their TI compiler. Your upstream url for this package is even pointing to TI's version of the compiler.

The msp430-elf-gcc-bin package incorrectly assumes that this package contains the file. It doesn't. It never has. Look at the commit history for this PKGBUILD and you will not see it there. This package is being incorrectly flagged as an optional dependency. The maintainer of msp430-elf-gcc-bin did not do their due diligence in testing (or in packaging for that matter) what they were shipping. Had they done so, they would have realized the file was missing and would have said something about it. I do not provide support for TI's own fork of the GCC-based toolchain. Period. The packager of that toolchain did not do their work properly and I am not going to fix their mistake.

It sounds like you didn't do enough testing if your package never supported the officially sanctioned GCC toolchain. It's as much your fault for choosing to name your set of packages using the exact prefix and naming scheme used by the official version of the compiler as it is his/hers for ignoring the warning message you get from having the missing devices.csv.

Updates are provided as they are released by mainline sources, not by TI's releases. Otherwise we would be stuck in an old version of gcc/binutils/newlib. Like I said, if those patches make it into a release, then devices.csv will be added. Otherwise, no. As a matter of fact, I asked a long time ago regarding the use of patches in this toolchain only to be told that I should be making packages from upstream, which I am [1]. Consequently, I only patch when there are bugs that need fixing.

Nope, again, that may be true for your packages of the GCC toolchain but that has nothing to do with this package given that this is a set of headers and support files that are virtually unaffected by differing compiler versions.

They are asking for the file because somebody else, who has yet to say something in this argument, incorrectly flagged this as an optional dependency without testing. The same person, I may add, whose only other package is one that provides the same functionality as a series of packages that are already in Community; but again, not my job to monitor the AUR. What should be expected is that a packager tests their own package before submitting it. The toolchain I maintain works and I have gone through several steps to ensure it is functional. There have been times where I have had to provide extra patches to fix bugs that would otherwise generate bad code or crash the compiler. I do not mind if another person puts a binary version, that is their choice, but I expect that person to do their due diligence and ensure that the software they are providing works as intended.

Incorrect, there are as far as I can tell no other versions of TI's GCC compiler in community, or AUR for that matter. It's fair that he/she could've done better testing, but it's also fair that it'd only take the addition of one file to your package to avoid this argument entirely and provide compatibility with both versions of the GCC toolchain. But I guess you get to choose which anthill you want to die on

Greetings,

It's disingenuous in that the TI toolchain is the de facto toolchain for the MSP430 microcontroller, and consequently support for it is presumed unless clearly denoted otherwise.

If we are going to go there, the defacto toolchain for MSP430 is the proprietary one provided by TI in Code Composer Studio. The linker scripts utilized by that toolchain are not compatible with GCC/LD and they use different header files as well. The GCC/Binutils effort was something that came out from having cheap development boards (the launchpad series) and no tools that could be freely distributed like the AVR/Arduino stack. Take from that what you will.

The file is not missing from msp430-elf-gcc-bin, it is missing from the support files, which are presumably provided by your package based on the package name and description, and therefore your package is broken by not providing all the support files.

The msp430-elf-gcc-bin package incorrectly assumes that this package contains the file. It doesn't. It never has. Look at the commit history for this PKGBUILD and you will not see it there. This package is being incorrectly flagged as an optional dependency. The maintainer of msp430-elf-gcc-bin did not do their due diligence in testing (or in packaging for that matter) what they were shipping. Had they done so, they would have realized the file was missing and would have said something about it. I do not provide support for TI's own fork of the GCC-based toolchain. Period. The packager of that toolchain did not do their work properly and I am not going to fix their mistake.

Once again, that point's irrelevant to the discussion at hand. If TI updates their compiler, they'll also update the support files (the ones you're already using as a source) as well.

For the record, it is not TI the one who maintains the MSP430 backend. It is a company they contract to do so for them. So far, they are on the third (first Red Hat, then Somnius, and now Mitto Systems). The MSP430 backend gets little attention, with bugs remaining open for months to years. Just look at the GCC/Binutils/Gdb bug tracker.

Any nonsense involved in supporting it in your version of the compiler doesn't change the fact that you'll be responsible for updating this package to the latest version of their headers anyways.

Updates are provided as they are released by mainline sources, not by TI's releases. Otherwise we would be stuck in an old version of gcc/binutils/newlib. Like I said, if those patches make it into a release, then devices.csv will be added. Otherwise, no. As a matter of fact, I asked a long time ago regarding the use of patches in this toolchain only to be told that I should be making packages from upstream, which I am [1]. Consequently, I only patch when there are bugs that need fixing.

This will avoid people asking about missing TI-specific files anyways, assuming you're actually providing what's expected, ie. all of the support files instead of just the ones you need for your version of the compiler

They are asking for the file because somebody else, who has yet to say something in this argument, incorrectly flagged this as an optional dependency without testing. The same person, I may add, whose only other package is one that provides the same functionality as a series of packages that are already in Community; but again, not my job to monitor the AUR. What should be expected is that a packager tests their own package before submitting it. The toolchain I maintain works and I have gone through several steps to ensure it is functional. There have been times where I have had to provide extra patches to fix bugs that would otherwise generate bad code or crash the compiler. I do not mind if another person puts a binary version, that is their choice, but I expect that person to do their due diligence and ensure that the software they are providing works as intended.

In summary, the file is not getting added until an official release from upstream (FSF) needs it.

Cheers,

Orlando.

[1] https://bbs.archlinux.org/viewtopic.php?id=209133

It's disingenuous in that the TI toolchain is the de facto toolchain for the MSP430 microcontroller, and consequently support for it is presumed unless clearly denoted otherwise.

The file is not missing from msp430-elf-gcc-bin, it is missing from the support files, which are presumably provided by your package based on the package name and description, and therefore your package is broken by not providing all the support files.

Once again, that point's irrelevant to the discussion at hand. If TI updates their compiler, they'll also update the support files (the ones you're already using as a source) as well. Any nonsense involved in supporting it in your version of the compiler doesn't change the fact that you'll be responsible for updating this package to the latest version of their headers anyways. This will avoid people asking about missing TI-specific files anyways, assuming you're actually providing what's expected, ie. all of the support files instead of just the ones you need for your version of the compiler