[Bug 1350884] Review Request: mspgcc - Rebase of GCC for the MSP430 to TI / Red Hat upstream

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1350884

Jonathan Wakely <jwakely@xxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely@xxxxxxxxxx



--- Comment #35 from Jonathan Wakely <jwakely@xxxxxxxxxx> ---
(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 would check whether it's possible to replace the "*-devel" lines with
> > "pkgconfig(foo)" like you did in the other cases.
> > 
> 
> I don't see a pkgconfig provided by gmp-devel or libmpc-devel.

Right.

> I got rid of the remaining libtool archive. I'm afraid I don't understand
> what header files or static objects shouldn't be there. This is a compiler,
> those are required for it to function.
> 
> > Package Review
> > ==============
> > 
> > Legend:
> > [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
> > [ ] = Manual review needed
> > 
> > 
> > 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.


> > - 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.



> > 
> > 
> > ===== 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.



> > [!]: Changelog in prescribed format.
> >      Macros in changelog are not allowed.
> 
> I'm not actually using the macro, it's just a comment. Should I escape it
> somehow? Or just modify the comment.

As mentioned in comment 33, either remove it or escape it with %%.


> > [!]: 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.

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.


-- 
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




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux