https://bugzilla.redhat.com/show_bug.cgi?id=1350884 --- Comment #36 from Brandon Nielsen <nielsenb@xxxxxxxxxxx> --- (In reply to Jonathan Wakely from comment #35) > (In reply to Brandon Nielsen from comment #32) > > Spec URL: > > https://copr-be.cloud.fedoraproject.org/results/nielsenb/msp430-development- > > tools/fedora-rawhide-x86_64/01577708-msp430-elf-toolchain/msp430-elf- > > toolchain.spec > > > When creating the symlinks for the binutils executables I'd be tempted to do: > > > # Symlink binutils so we can build GCC > mkdir bin > for i in addr2line ar cxxfilt elfedit gprof libtool objcopy objdump ranlib > readelf size strings > do > ln -sr binutils/binutils/$i bin/%{target}-$i > done > for i in as ld nm strip > do > ln -sr binutils/binutils/$i-new bin/%{target}-$i > done > > Personally I find it a bit easier to read because it's less of a wall of > text, and it's clear which ones are linked using the same name and which > ones aren't. But that's just me, what you have is fine. > > I don't think building GCC actually needs most of these, but it doesn't hurt > to add them. > I could feasibly do away with the renaming entirely and use the '--program-prefix' configure option (see additional discussion below)? No matter what, I like your solution better. [Snip] > > > Issues: > > > ======= > > > - Header files in -devel subpackage, if present. > > > **Lots of leftover header files in subdirs of /usr/msp430-elf** > > > See: https://docs.fedoraproject.org/en-US/packaging- > > > guidelines/#_devel_packages > > > > It's a compiler, the headers are necessary as far as I'm aware. > > It's possible the msp430-elf-gcc package won't actually work without some of > those headers, so there's no benefit to putting them in a separate -devel > package. > > But it's not true for all of them. > > The files in /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/plugin/ are not > strictly necessary to use the compiler, only if you want to build GCC > plugins for msp430-elf. You could either not bother packaging the plugin > support at all, or you could leave it in the main msp430-elf-gcc package > (which is what the avr-gcc package appears to do too). > > The files in /usr/msp430-elf/msp430-elf/include/ appear to be the newlib > libc headers. In theory they could be put in a separate > msp430-elf-newlib-devel subpackage. Code which doesn't use anything from the > C standard library could still be compiled by msp430-elf-gcc without the > newlib headers. > I've waffled back and forth on the plugin headers since I've started trying to package this. Ultimately, the "upstream" (such that it is) binary packages include them last I checked, so I figured I would as well. Same with the newlib headers. I could check again, but at some level, if I'm shipping most of the headers, why not just ship all? > > > - Static libraries in -static or -devel subpackage, providing -devel if > > > present. > > > Note: Package has .a files: msp430-elf-gcc, msp430-elf-gcc-c++. Illegal > > > package name: msp430-elf-gcc, msp430-elf-gcc-c++. Does not provide > > > -static: msp430-elf-gcc, msp430-elf-gcc-c++. > > > See: https://docs.fedoraproject.org/en-US/packaging- > > > guidelines/#packaging-static-libraries > > > > Again, this is a compiler, as far as I know, those are necessary. > > Again, true for some of those libs that msp430-elf-gcc depends on, but not > true for the ones in msp430-elf-gcc-c++. > > Fedora's native GCC package puts the C++ standard library headers and libs > into separate packages, not part of gcc-c++. Specifically, libstdc++-devel > and libstdc++-static. > > That means the gcc-c++ package can be used to compile C++ code that doesn't > depend on the standard library or the C++ runtime. But for most practical > uses you also need to install libstdc++-devel (and for static linking, > libstdc++-static as well). > > > That said, this seems like a reasonable way to split the packages up. > There's probably not much practical benefit to more granularity for the > stdlib files. > avr-gcc doesn't appear to do this, I can check the other cross compilers. I'm open to either really. > > > > > > > > > > ===== MUST items ===== > > > > > > C/C++: > > > [x]: Package does not contain kernel modules. > > > [?]: Package contains no static executables. > > > [!]: Development (unversioned) .so files in -devel subpackage, if present. > > > Note: Unversioned so-files in private %_libdir subdirectory (see > > > attachment). Verify they are not in ld path. > > > > I agree this is gross, but it's not in "regular" gcc's ld path, so I think > > it's okay? > > Yes, I think these are OK where they are: > > msp430-elf-gcc: > /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/plugin/libcc1plugin.so > msp430-elf-gcc: > /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/plugin/libcp1plugin.so > msp430-elf-gcc: /usr/msp430-elf/libexec/gcc/msp430-elf/9.2.0/liblto_plugin.so > > They're specific to this build of GCC, and won't be used by anything else. > I will remove them. [Snip] > > > [!]: Fully versioned dependency in subpackages if applicable. > > > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in > > > msp430-elf-gcc , msp430-elf-gcc-c++ , msp430-elf-gdb , msp430-elf- > > > binutils > > > Review: it's a good idea to include this. > > > > I'm not sure I understand. I've added some missing requires (the C++ > > compiler now requires the C compiler, the C compiler now requires binutils), > > but if I add the "Requires: {name}%{?_isa} = %{version}-%{release}" > > requested, I just get packages that are uninstallable. Is there some > > documentation I can look at to see an example of what's being requested? > > I think you want %{?_isa} to be present on the Requires tags, otherwise it's > possible for a user to manually install the 32-bit msp430-elf-binutils.i686 > package on an x86_64 and have that satisfy the requirement for > msp430-elf-binutils. But what you're really trying to require is the > msp430-elf-binutils.x86_64 one, so you need the %{?_isa} suffix. > Thanks, I understand now. > I agree that you don't want the subpackages to require the main one, but > that's because the main one doesn't actually exist ... no > msp430-elf-toolchain package actually gets created. > > Shouldn't that main package be an umbrella package that installs the others, > i.e. the main package should have: > > Requires: %{name}-binutils%{?_isa} = %{version}-%{release} > Requires: %{name}-gcc%{?_isa} = %{version}-%{release} > Requires: %{name}-gcc-c++%{?_isa} = %{version}-%{release} > Requires: %{name}-gdb%{?_isa} = %{version}-%{release} > > That would allow you to say 'dnf install msp430-elf-toolchain' and get all > of the subpackages at once. That's a good idea! My only thought is I don't actually know many developers doing C++ on embedded, but I like the idea of being able to get the complete toolchain. An additional question, since I've moved to setting the '--prefix=%{_prefix}/%{target}' on configure, I've needed to add a matching '-B/usr/bin/msp430-elf-' to any Makefile using the resulting compiler. Would setting the program prefix, instead of adding the prefix with my symlinks, fix this? One final question, do I need to run add a check step? They used to not work, but I think they do now. -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
