[Bug 1350884] Review Request: mspgcc - Rebase of GCC for the MSP430
to TI / Red Hat upstream
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1350884
--- Comment #56 from Brandon Nielsen <nielsenb(a)jetfuse.net> ---
(In reply to Andy Mender from comment #55)
> > Okay, looking into this more (also see comment 11, comment 12, comment 13, comment 14), the biggest issue I see is that it should be marked as bundled with gdb and binutils, not gcc. I don't think there's actually a bundled gnulib in gcc. That's probably why I was confused above. Assuming the ChangeLog is correct, I will version it with a date as done in system gdb[0].
>
> I checked the regular gcc package and yes, it's not there:
> https://src.fedoraproject.org/rpms/gcc/blob/master/f/gcc.spec
> It's bundled with gdb, however:
> https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb.spec#_105
>
And for some reason this tarball bundles (a different version!) with binutils
as well. I'm now versioning both with the last date in the ChangeLog, based on
this quote[0] from the packaging guidelines: "A very general rule of thumb is
to use the oldest version that seems reasonable as the reason we're doing this
is to tell when a library contains issues that have been fixed in newer
upstream versions.".
> > I'm not sure I understand. In comment 23, comment 24, comment 25, and comment 35 it was decided to move everything to the /usr/msp430-elf prefix and symlink prefixed binaries as described in the packaging guidelines[1]. Why are we now moving things back to unprefixed system %{_libdir}? These unprefixed binaries should never come into contact with any non-msp430 compiler, and as far as I can tell getting rid of them breaks compatibility with how "upsteam" (TI, so, more midstream...) intends the compiler to work, which as far as I'm concerned would make this package a little pointless.
>
> Yes, you're right. Apologies for my previous comment. I confused myself. The
> way it is right now makes more sense, of course. Let's keep that part as it
> is now.
Don't worry about it, this has turned into quite the epic.
As for the dangling symlink weirdness from comment 53, it seems to be a bug[1].
cc1plus is excluded from msp430-elf-gcc so it doesn't get packaged. But for
some reason the debuginfo symlink makes it into both the msp430-elf-gcc and
msp430-elf-gcc-c++ debuginfo packages.
I'm still looking into what's going on with armhfp. I don't fully understand
the s390x issue either, but since that's an alternative architecture it's less
of a problem, right?
[0] -
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Lib...
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=878863
--
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
3 years, 5 months