https://bugzilla.redhat.com/show_bug.cgi?id=1350884
--- Comment #54 from Brandon Nielsen <nielsenb(a)jetfuse.net> ---
(In reply to Andy Mender from comment #53)
Extra Koji build from the latest SRPM:
https://koji.fedoraproject.org/koji/taskinfo?taskID=55638767
Fails on s390x, but I don't think it's the SRPMs fault.
Interesting. It's more interesting that the built compiler just doesn't really
work at all on armv7.
> It now carries a patch file, 2 actually, to work around issues
with the GDB tests. There are actually lots of failures with the GDB tests, so I limited
the suite to gdb.base to make it more workable. There were additional issues with GDB ix86
tests, so that carries an additional patch. I think patching conditionally based on
architecture is okay?
rpmlint has mixed feelings about this, but I think it's okay:
> msp430-elf-toolchain.src: W: %ifarch-applied-patch Patch1:
msp430-elf-toolchain_i386_testfix.patch
I found this, though:
https://listman.redhat.com/archives/fedora-devel-list/2007-September/
msg01515.html
Yup, already stumbled across that particular failure. I also really don't like
the idea of an architecture specific patch in general, but it's a little more
palatable for a test.
> Provides: bundled(gnulib)
Didn't notice this before, but rpmlint complains that this should be
versioned:
> msp430-elf-toolchain.src:61: W: unversioned-explicit-provides bundled(gnulib)
Which does make sense, because without versioning it's impossible to tell
which gnulib it is. Unless, it's not possible to ascertain, because the
source is a tarball and not much more.
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].
> case $a in
> # Prevent brp-strip* from trying to handle foreign binaries
> */brp-strip*)
> b=$(basename $a)
> sed -e 's,find "*$RPM_BUILD_ROOT"*,find "$RPM_BUILD_ROOT"
-not -path
"%{buildroot}%{_prefix}/%{target}/lib/gcc/%{target}/%{gcc_version_base}/*" -not
-path "%{buildroot}%{_prefix}/%{target}/%{target}/lib/*",' $a > $b
> chmod a+x $b
> ;;
> esac
> done
Is it possible to use %{buildroot} instead of $RPM_BUILD_ROOT in the sed
call? Both should expand to the same path.
As mentioned in comment 32, comment 34, I'm not using the variable, I'm
replacing the literal string "$RPM_BUILD_ROOT" in the strip macro.
rpmlint also complains about quite a lot of header files in the main
subpackages:
> msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package
/usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libgcc.a
> msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package
/usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libgcov.a
> msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package
/usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_16.a
> msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package
/usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_32.a
> msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package
/usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_f5.a
> msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package
/usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_none.a
> [...]
I'm guessing these are needed by the main packages and the lines can be
ignored?
Not sure about these, though:
> msp430-elf-gcc.x86_64: W: dangling-relative-symlink
/usr/lib/.build-id/3d/b4b5215ce578d5b13456988092f30187ac4beb
../../../../usr/msp430-elf/libexec/gcc/msp430-elf/9.2.0/cc1plus
This symlink doesn't look valid. Is it an artifact from the build?
I'm not entirely sure on that one. Looking into it now.
> msp430-elf-binutils.x86_64: W: non-standard-dir-in-usr msp430-elf
> Additionally, unprefixed symlinks to the executables are now made in
/usr/msp430-elf/msp430-elf/bin as their presence is expected by the generated
msp430-elf-gcc. I don't fully understand why. This eliminates the need for the
-B/usr/bin/msp430-elf- compile option, maintaining better compatibility with Makefiles.
Again, I'm sure there's a better way but I don't know it.
Yeah, rpmlint complains about that, too. This is a bit of a deal breaker.
Things should go into %{_libdir} typically.
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.
[0] -
https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb.spec#_105
[1] -
https://fedoraproject.org/wiki/Packaging_Cross_Compiling_Toolchains#Cross...
--
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