Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1175942
Summary: | Fails to link | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | James Boulton <j.boulton> |
Component: | msp430-gcc | Assignee: | Orphan Owner <extras-orphan> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | kannanaswinvenu, nielsenb, rob, swhiteho, yamaplos |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-12-20 13:08:30 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
James Boulton
2014-12-18 23:14:05 UTC
I've just installed fedora 21 x86_64 and have the same problem. It seems that the linker is trying to include it's own libraries (i.e. -lgcc -lcrt0) in the link of the MSP430 objects which are not MSP430 processor objects. Thus they are rejected and the link fails. I found this explanation on the TI site. Although it's on code composer it still uses the GCC compiler. http://2e.ti.com/support/development_tools/code_composer_studio/f/81/p/245089/860104 Hi, I have tried adding -sysroot=/usr/msp430/ so as remove the unwanted lis, but got: /usr/lib64/gcc/msp430/4.6.4/../../../../msp430/bin/ld: this linker was not configured to use sysroots collect2: ld returned 1 exit status Also the jean-filip tripcevic url fails hopefully this is the thread he refers to: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/245089/860104 I've compared the two libraries that fail (libgcc.a and libcrt0.a) with those on my fedora 20 box which work. Both the msp430 compiler and linker on fedora 20 and 21 are the same versions. 4.6.4 for gcc and 2.21.1 for ld. Doing an msp430-objdump on the libraries I get an error for the first object file in each library on fedora 21 but not on fedora20. Here are the errors I get. For libcrt0: _reset_vector__.o: file format elf32-little msp430-objdump: can't disassemble for architecture UNKNOWN! and for libgcc: _cmpsi2.o: file format elf32-little msp430-objdump: can't disassemble for architecture UNKNOWN! The rest of the object files contained in the libraries disassemble without any problems. I'll try replacing these libraries with those on F20 when I get some time and post the results. I replaced libgcc.a and libcrt0.a on my F21 box with libgcc.a and libcrt0.a from my F20 machine and the link now works. So it appears that these libraries on F21 have a problem with the first objects contained in the archrives. There are several copies to replace and they are all bad. /usr/lib64/gcc/msp430/4.6.4/libgcc.a /usr/lib64/gcc/msp430/4.6.4/mcpu-430x/libgcc.a /usr/lib64/gcc/msp430/4.6.4/mcpu-430x/mmpy-16/libgcc.a /usr/lib64/gcc/msp430/4.6.4/mmpy-16/libgcc.a and /usr/lib64/gcc/msp430/4.6.4/mcpu-430x/libcrt0.a /usr/lib64/gcc/msp430/4.6.4/mcpu-430x/mmpy-16/libcrt0.a /usr/lib64/gcc/msp430/4.6.4/mmpy-16/libcrt0.a /usr/lib64/gcc/msp430/4.6.4/mmpy-16/libcrt0dwdt.a The problem also exists on the 32-bit F21. One last note: I downloaded the msp430-gcc source package and compiled it on my F21 machine. The libraries it made had the problem so it appears to be a problem when the libraries are put in the archive. It's only the library archive that's bad. The object files generated by the compiler don't have the problem. For example when I look at libgcc.a I get this: $ msp430-objdump -d libgcc.a In archive libgcc.a: _cmpsi2.o: file format elf32-little msp430-objdump: can't disassemble for architecture UNKNOWN! But when I look at the _cmpsi2.o object file It's OK $ msp430-objdump -d _cmpsi2.o _cmpsi2.o: file format elf32-msp430 Disassembly of section .text.libgcc: I manually made an archive using the generated object files and it was OK The problem comes from stripping out the symbols from the archive after it was built. I looked at the library archives before being stripped and they did not produce any errors whereas the archives after stripping produced errors. The F21 GNU strip command (version 2.24) differs from the F20 GNU strip (version 2.23.2). You can get around the problem by extracting the object files from the archive then with a hex editor edit the corrupted file by replacing offset 0x12 which has a value of 00 with a value of 0x69 (Texas Instrument msp430 cpu type), saving the file then remake the archive with msp430-ar. Of course the better would be to find out why strip is changing the e_machine type in the elf header (for only first object in the archive) to unknown. I have the above problem as well. Additionally, the version of GCC and the support files provided by these packages is quite old now, and have been superseded by a joint TI / Red Hat effort to provide an open toolchain: http://www.ti.com/tool/msp430-gcc-opensource Unfortunately, they don't package it (at least not for Fedora). Where licensing allows, I have created RPMs and added them to a set of copr repositories. GCC, GDB, binutils: https://copr.fedoraproject.org/coprs/nielsenb/msp430-elf-gcc/ MSP430 support files / linker scripts: https://copr.fedoraproject.org/coprs/nielsenb/msp430mcu/ MSP debug stack: https://copr.fedoraproject.org/coprs/nielsenb/mspds/ MSP430Flasher utility: https://copr.fedoraproject.org/coprs/nielsenb/msp430flasher/ If you want to try them, please remove your current msp430-gcc, msp430-binutils, msp430-gdb, msp430mcu, msp430-libc, and mspdebug packages. There is no direct replacement for mspdebug. Flashing is handled via the MSP430Flasher utility. The GDB bridge is now created via the XDS GDB Agent (which I am not allowed to package), it is available here: http://processors.wiki.ti.com/index.php/XDS_GDB_Agent If you choose the use the XDS GDB Agent, note that it requires the i686 version of the MSP debug stack to be installed as well. So far, everything has compiled for me with only minor changes (change msp430-gcc to msp430-elf-gcc in Makefiles, use new interrupt format, etc.). I've updated my packaging of the official TI / Red Hat GCC sources and moved everything to a single Copr repo: https://copr.fedoraproject.org/coprs/nielsenb/msp430-development-tools/ I Have also faced the same problem! Ofcourse you may have some problem with missing of libmsp430.so file while using tilib. I have done some thing tricky to solve both these problems. you might heard about energia project. http://energia.nu/ It uses msp430-gcc for compiling!! So ofcourse it contains pre built version of msp430-gcc go and download the file from here http://energia.nu/download/ then from energia/hardware/tools/msp430/ use the msp430-gcc !!!! thats it. It is working cool...!! you can also find libmsp430.so file in energia/hardware/tools/msp430/bin/ use that for tilib enjoy coding :) Thank you, Aswin. For a while your suggestion was the only way I could use my MSP430 Launchpad on Fedora 22. Finally today I managed to get to work (almost) all of the updates that Brandon made available. for other noobs out there, as used in Fedora 22 XFCE INSTALL TOOLCHAIN - open a Terminal window sudo dnf copr enable nielsenb/msp430-development-tools (enter your password) sudo dnf install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files dos2unix I am at a loss on how to use MSP430Flasher. So I use mspdebug sudo dnf install mspdebug USAGE assuming you have ready: - MSP430 Launchpad with MSP430g2553 (vanilla "out-of-the-box") connected to your USB port - a file with C code, mycode.c this instruction will compile mycode.c, and output outfile.o : msp430-elf-gcc -mmcu=msp430g2553 mycode.c -o outfile.o and this will upload the compiled code to the MCU: sudo mspdebug rf2500 "prog outfile.o" This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. This is still happening on F23. Rob, is there any reason why the Fedora mspgcc should not be moved to the new toolchain now? Not that I know of. I've stopped using the toolchain, as pretty much every project I work on now is cortex-m based. Can I hand on the maintenance to someone else who has an interest in maintaining it? I don't really have time to look after it either. I'd suggest that best thing to do would be to do the orphan package procedure which will allow time for someone else to pick it up. I think the details are listed on the Fedora project site of how to do that. If switching to the newer RedHat / TI joint toolchain like I package in my Copr above would be acceptable, I could maintain it. Not sure the fact the debugger isn't real useful without the proprietary TI XDS GDB agent is okay though. That, and the fact I'd be a new maintainer, are the two reasons I hadn't suggested it. Link to Copr: https://copr.fedoraproject.org/coprs/nielsenb/msp430-development-tools/ Well if the current package is not working, then there is nothing to lose by switching to the newer toolchain. It was always the plan to switch at some stage. We are always happy to encourage new people to become maintainers for Fedora. You may have to go through a new package review process in order to do that, even though it is not really a new package. The details are all on the Fedora site. If you get stuck let me know and I'll see what I can do to assist. I'm okay with going through the review process, just didn't want to step on any toes. Do you have any contact with the group at RedHat or TI that does the toolchain? I often have issues packaging the latest releases due to either broken links, or links to the wrong thing. When I go through generic support channels at TI, it often takes months to get it resolved. For instance, the link to the latest open source release of the debug stack is broken, I've contacted their website support, but have gotten nowhere: http://www.ti.com/tool/mspds Submitted the GCC package for review: https://bugzilla.redhat.com/show_bug.cgi?id=1350884 Once I get sponsored and the package gets cleared, I'll start the process for MSP430Flasher and mspds. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |