MSPM0L1306: liblto_plugin.so: file too short

Hi Hans,

Thank you for your post. To clarify, this example is building now on your end? How did you install the GCC compiler tools? Did you manually download them or install through the CCS dialog?

I am going to try to recreate this on my end. 

Best Regards,
Brandon Fisher

Hi Brandon,

Installed via the import to CCS function in the resource explorer.

It builds correctly after this fix.

Hi Hans,

What OS and version are you running? I was not able to recreate this in my windows environment after installing the GCC Arm Compiler tools via CCS.

Best Regards,
Brandon Fisher

Hi Brandon,

Ubuntu 22.04 LTS.

Are you building Linux installers on Windows? That might explain the issue I guess...

Thanks Hans,

Since this is CCS/Installer specific, our software and tools team is more likely to be useful here. They would have tested this in Linux after building the installer, although I am ignorant of the details of their process. 

I will forward this thread to that team for comment. 

Best Regards,
Brandon Fisher

Brandon Fisher94 said:

I was not able to recreate this in my windows environment after installing the GCC Arm Compiler tools via CCS.

I was also unable to recreate the issue when used CCS 12.3.0 under Ubuntu 18.04.6 LTS:

$ ls -l ~/ti/ccs1230/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin*
-rwxr-xr-x 1 mr_halfword mr_halfword 84928 Oct 30  2019 /home/mr_halfword/ti/ccs1230/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so
-rwxr-xr-x 1 mr_halfword mr_halfword 84928 Oct 30  2019 /home/mr_halfword/ti/ccs1230/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so.0
-rwxr-xr-x 1 mr_halfword mr_halfword 84928 Oct 30  2019 /home/mr_halfword/ti/ccs1230/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so.0.0.0

But it looks a bit odd that the CCS installer 3 files named liblto_plugin.so, liblto_plugin.so.0 and liblto_plugin.so.0.0.0 rather than one file and 2 symlinks.

Have yet tried to re-create the issue with installation of the GCC compiler in the resource explorer under Linux.

Strange, your path is differing from mine. I had to install the GCC compiler tools and I directed it to the utils directory since I don't want to have a directory for every vendor under the sun in my homedir. I chose utils.

If I do an ls -l on the utils/gcc_ ... I get:

hans@tomaat:~/bin/ccs1230/ccs/utils/gcc_arm_none_eabi_9_2_1$ ls -l lib/
total 780
drwxrwxr-x 3 hans hans 4096 jul 27 18:09 gcc
-rwxrwxr-x 1 hans hans 15 jul 27 18:09 libcc1.so
-rwxrwxr-x 1 hans hans 15 jul 27 18:09 libcc1.so.0
-rwxr-xr-x 1 hans hans 782696 jul 27 18:09 libcc1.so.0.0.0

In hindsight I already have the compiler on my system in the same path as your install:

hans@tomaat:~/bin/ccs1230/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major$ ls -l lib/
total 2308
drwxrwxr-x 3 hans hans 4096 jul 27 18:03 gcc
-rwxr-xr-x 1 hans hans 782696 okt 30 2019 libcc1.so
-rwxr-xr-x 1 hans hans 782696 okt 30 2019 libcc1.so.0
-rwxr-xr-x 1 hans hans 782696 okt 30 2019 libcc1.so.0.0.0

Same behavior as on your installation. Problem is, that compiler directory is not recognized in the IDE...

Hans Nieuwenhuis said:

Installed via the import to CCS function in the resource explorer.

As a test just installed CCS 12.3.0.00005 in an AlmaLinux 8.7 live CD (so no previous CCS install). Just selected MSPM0 Support during the CCS install. Once CCS 12.3 installed then selected to install the MSPM0 SDK 1.10.00.05 from the Resource Explorer, and let the Resource Explorer install the ARM GCC 9.2.1 dependency (had to use /tmp as the install directory just to prevent the live CD running of of disc space).

With the Resource Explorer installer the liblto_plugin.so file is just a ASCII file containing "liblto_plugin.so.0.0.0" rather than an actual symbolic link:

[liveuser@skylake-alma ~]$ ls -l /tmp/gcc_arm_none_eabi_9_2_1/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin*
-rwxrwxr-x. 1 liveuser liveuser    22 Jul 31 23:11 /tmp/gcc_arm_none_eabi_9_2_1/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so
-rwxrwxr-x. 1 liveuser liveuser    22 Jul 31 23:11 /tmp/gcc_arm_none_eabi_9_2_1/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so.0
-rwxr-xr-x. 1 liveuser liveuser 84928 Jul 31 23:11 /tmp/gcc_arm_none_eabi_9_2_1/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so.0.0.0
[liveuser@skylake-alma ~]$ file /tmp/gcc_arm_none_eabi_9_2_1/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so
/tmp/gcc_arm_none_eabi_9_2_1/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so: ASCII text, with no line terminators
[liveuser@skylake-alma ~]$ cat /tmp/gcc_arm_none_eabi_9_2_1/lib/gcc/arm-none-eabi/9.2.1/liblto_plugin.so
liblto_plugin.so.0.0.0

I.e. have re-created the issue with the Resource Explorer install of the ARM GCC 9.2.1 compiler under Linux.

Hans Nieuwenhuis said:

Problem is, that compiler directory is not recognized in the IDE...

In CCS under Window -> Preferences -> Code Composer Studio -> Build -> Compilers there is a "Tool discovery path". Looks like if there are multiple copies of the same compiler in the discovery path CCS will pick the first directory that a compiler version is found in. You could try editing the Tool discovery path to place ~/bin/ccs1230/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major first.

Ok, adding a slightly more specific path to that window did seem to work to select the already installed tool. Then I wonder why the CCS example import insisted on me installing the tool as it was already there...

So as a test I removed the tool install from my utils (rm -rf gcc_...) directory which was the install via the import wizard and restarted CCS. Then I reinstated the original search paths and the GCC install in the tools directory was instantly recognized.

After that I imported another sample project into CCS and it did not ask me to install the GCC compiler chain which is expected behaviour. I don't know why it asked me the first time though...

Anyway coming back to the symlink issue: both installs do not do it correctly as liblto and libcc1 should have proper symlinks under Linux (and Mac) instead of just copies (works but ugly) or textfiles with a name in it (broken).

Hi Brandon,

Brandon Fisher94 said:

Since this is CCS/Installer specific, our software and tools team is more likely to be useful here. They would have tested this in Linux after building the installer, although I am ignorant of the details of their process. 

CCS does not ship with GCC and the software and tools team does not officially support GCC. Hence there likely would not have been any testing with GCC.

I am able to reproduce the issue. I tried downloading the SDK from Resource Explorer, which in turn automatically downloaded GCC 9.2.1 as a dependency. Then when trying to build a GCC project from the SDK, I got the same error. It appears to be an issue with GCC package in Resource Explorer.

Yes, this is a known issue:

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1133058/launchxl-cc26x2r1-unable-to-build-code-on-ccs-12-using-ubuntu