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.