https://bugzilla.redhat.com/show_bug.cgi?id=1350884
--- Comment #24 from Andy Mender <andymenderunix(a)gmail.com> ---
Some of the URLs have moved slightly (or were maybe wrong from the
beginning), those will be fixed in the next revision.
I managed to find the latest sources here:
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/9_2_0...
I think one of your %global definitions should be:
%global ti_version_number 9_2_0_0
instead of:
%global ti_version_number 9_2_0_00
And the URL block should be a little different.
The documentation for packaging cross compilers[0] states "All
cross-compilers should add --prefix=/usr/arch-os-libc to ./configure when building the
toolchain. This is according to the cross-compiling guidelines in GCC's INSTALL
document." I cannot find this guideline in the GCC documentation[1]. I can do this of
course, but it results in /usr/msp430-elf/bin, /usr/msp430-elf/lib, etc... I have
experimented with this, and with symlinking the resulting binaries into /usr/bin (as noted
in the Fedora documentation), the compiler works as expected.
I would stick to the official Fedora packaging docs in this case. I'm not sure
why avr-gcc uses `--prefix=%{_prefix}`, but the docs you linked also mention
avr-gcc is a bit of a special case. Unfortunately, I don't have much experience
with packaging compilers.
So, I count 3 paths forward:
1: Specify prefix as per Fedora guidelines
2: Try to match avr-gcc, with everything going roughly where I would expect, binaries in
/usr/bin, library files in /usr/lib/gcc/avr, etc...
3: The terrible hybrid I've done in all the builds above, with binaries going in
/usr/bin, libraries and include files mostly going in /usr/msp430-elf/lib, but some going
in /usr/lib...
I would go with 1. in this case. Putting everything into a prefixed dir inside
`/usr` (`/usr/msp430-elf`, for instance) and then symlinking seems like a
cleaner and better self-contained approach than symlinking some of the files
and directly putting the rest into regular directories.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component