Bug 485416 - Review Request: msp430-gcc - Cross compiling GNU GCC for the MSP430
Review Request: msp430-gcc - Cross compiling GNU GCC for the MSP430
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Whitehouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-13 09:29 EST by Rob Spanton
Modified: 2009-04-21 21:10 EDT (History)
4 users (show)

See Also:
Fixed In Version: 3.2.3-2.20090210cvs.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-21 21:10:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
swhiteho: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
koji ppc64 build.log ending in failure. (213.24 KB, text/plain)
2009-02-13 09:32 EST, Rob Spanton
no flags Details
Diff against *.spec to address the issues mentioned previous comment (2.55 KB, patch)
2009-02-17 11:12 EST, Ralf Corsepius
no flags Details | Diff

  None (edit)
Description Rob Spanton 2009-02-13 09:29:41 EST
Spec URL: http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gcc.spec
SRPM URL: http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gcc-3.2.3-1.20090210cvs.fc10.src.rpm
Description: This is a Cross Compiling version of GNU GCC, which can be used to
compile for the msp430 platform, instead of for the native i386
platform.

The mspgcc project has maintained patches against gcc 3.2.3 for a long time.  The documented procedure for installing mspgcc is taking their patches and applying them against gcc.

I based this on the avr-gcc spec.

One rpmlint warning: 
msp430-gcc.spec:46: W: rpm-buildroot-usage %prep sed -e 's,find $RPM_BUILD_ROOT,find $RPM_BUILD_ROOT%_bindir $RPM_BUILD_ROOT%_libexecdir,' $a > $b

I don't believe this error is fatal.  The script needs to modify the os_install_post script so that the build system doesn't try to process the msp430 binaries with the tools for the host's architecture.

Build fails on ppc64 in koji, but succeeds on all the other arches (I shall attach the error message to this bug shortly).

I'd really appreciate a review of this.  Thanks :-D
Comment 1 Rob Spanton 2009-02-13 09:32:58 EST
Created attachment 331830 [details]
koji ppc64 build.log ending in failure.

As documented in specfile, build fails in koji for ppc64.  I attach the build.log for this failure.
Comment 2 Steve Whitehouse 2009-02-13 09:40:24 EST
Ok, I'll try and find time to have a look at this over the weekend.
Comment 3 Steve Whitehouse 2009-02-16 14:46:24 EST
Review comments:

Regarding comment #1, I think you need to open a separate bug for the ppc64 issues. That can then be addressed at a later date. It doesn't look like its likely to be a big issue to solve though, so it might be easier to solve it rather than open the bug.

I've been all though the review guidelines and thats all that I can find which isn't already done, so if we can resolve that, then I think its good to go.
Comment 4 Rob Spanton 2009-02-17 09:16:05 EST
Hi Steve,

Thanks for reviewing.

The packaging guidelines say: 

"New packages will not have bugzilla entries during the review process, so they should put this description in the comment until the package is approved, then file the bugzilla entry, and replace the long explanation with the bug number."

(https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Build_Failures)

I can't create a bug against msp430-gcc until it exists in bugzilla!
Comment 5 Steve Whitehouse 2009-02-17 09:25:28 EST
Ah, indeed :-)

I think the review guidelines perhaps need updating in that case, since they say that if an arch doesn't build then it must be listed in ExcludeArch (which I see that you've done) and a bugzilla must be opened.

Either way, do you think it would be possible to fix this by adding a small patch somehow? I suspect its just some missing/extra #define or something thats given us two definitions of that one thing. The messages to me don't indicate a major issue.

If you think its going to be too tricky, then we can just go ahead without PPC64 for now, but it would be better to fix it if possible.
Comment 6 Ralf Corsepius 2009-02-17 11:10:32 EST
(In reply to comment #1)
> Created an attachment (id=331830) [details]
> koji ppc64 build.log ending in failure.
> 
> As documented in specfile, build fails in koji for ppc64.  I attach the
> build.log for this failure.
This build fails, because you are not correctly passing CFLAGS to configure.

You need to override CC in configure
CC="%{__cc} ${RPM_OPT_FLAGS}" ./configure

Then it builds: http://koji.fedoraproject.org/koji/taskinfo?taskID=1133315

Other issues:
* MUSTFIX: Your package must own %{_libdir}/gcc-lib

* CONSIDER: The libexecdir warnings you observe, originate from this antiquated GCC not to install anything to below %_libexecdir.
(Newer gcc's install internal binaries to %_libexecdir/gcc/<target>/<version>, ancient GCCs install them to %{_libdir}/gcc-lib/<target>/<version> and mix them up with target binaries)
=> the whole debug_info/brp-strip hacks are non-functional in this case.

You have 2 alternatives to address this:
a) Fix the sed call to hack up brp-strip in such a way it only picks up the host-executables

b) Remove all the hack entirely and live with the warnings brp-strip issues
However, you seem to be lucky, this seems possible in this case, because brp-strip etc. (at least on Fedora 10) are broken enough not to try corrupting your target's files.


* CONSIDER: I would change your %prep/%setup into
%prep
%setup -q -T -c
%setup -q -T -D -a0
%setup -q -T -D -a1
(But that's just my personal preference.)

* CONSIDER: Instead of removing the *.1's you could rename them into %{target}-*.1
(A bug having been fixed in upstream GCCs for several years).


Finally, I guess you know that gcc-3.2.3 is dead and discontinued for ca.
5 years - Not actually something I would want to maintain ;-)
Comment 7 Ralf Corsepius 2009-02-17 11:12:41 EST
Created attachment 332240 [details]
Diff against *.spec to address the issues mentioned previous comment
Comment 8 Rob Spanton 2009-02-28 14:44:10 EST
Hi Ralf, 

Thanks.  The CFLAGS issue that you spotted fixes building against rawhide on ppc64.  However, it doesn't fix building against F10:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1208914

So, I can either lean towards rawhide here or F10.  Disabling the ppc64 build will make both work, but there'll be no ppc64 in rawhide.  Once it's in CVS, I can enable the ppc64 build for rawhide.  Does that sound like a sensible strategy?

> b) Remove all the hack entirely and live with the warnings brp-strip issues
> However, you seem to be lucky, this seems possible in this case, because
> brp-strip etc. (at least on Fedora 10) are broken enough not to try corrupting
> your target's files.

Unfortunately this doesn't work.  The brp-strip stuff does touch the libgcc.a file, resulting in an unusable compiler.

I had a look at hacking the brp-strip scripts up more, but I can't see the problem with them.  The output of: 

rpm -ql msp430-gcc | while read f; do file $f | grep ELF | grep -v stripped; done

All the host binaries are stripped successfully when the brp-strip hacking is in place.

I've added your suggestions for the setup macro (I can't believe that one has to read the RPM source to find out what those %setup parameters mean.  Terrible!) and moved the man pages.

> Finally, I guess you know that gcc-3.2.3 is dead and discontinued for ca.
> 5 years - Not actually something I would want to maintain ;-)

Unfortunately, this is the situation with mspgcc.  Most of the mspgcc development is focussed on 3.2.3.

Yes, this is a pain.  However, hopefully packaging it up and making it available in a major distribution will help to breathe life into the project.  Once people start using it, I think they'll begin to appreciate why using those non-free compilers is an inferior option.

As I'm sure you're aware, it's mighty difficult to get started on GCC hacking.  I don't really see how we can get out of this situation until that changes :-/

New files:
Spec file: http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gcc.spec
SRPM: http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gcc-3.2.3-2.20090210cvs.fc10.src.rpm

Rob
Comment 9 Steve Whitehouse 2009-03-10 04:30:00 EDT
Ralf, are you happy with the changes which Robert has applied? If so then I think we can move to the next stage.

Robert, your plan for enabling PPC64 later seems perfectly sensible to me. Sorry for the delay in reponding.
Comment 10 Steve Whitehouse 2009-03-20 12:57:39 EDT
I've not heard from Ralf yet, but everything looks in order so I'm going to approve this now and we can tidy up any loose ends as we go.
Comment 11 Ralf Corsepius 2009-03-23 12:01:26 EDT
(In reply to comment #10)
> I've not heard from Ralf yet,
Sorry, but this package had dropped off my radar - Apologies.
Comment 12 Rob Spanton 2009-03-26 16:19:16 EDT
New Package CVS Request
=======================
Package Name: msp430-gcc
Short Description: Cross Compiling GNU GCC targeted at msp430
Owners: rspanton
Branches: F-10
InitialCC:
Comment 13 Kevin Fenzi 2009-03-27 16:12:40 EDT
cvs done.
Comment 14 Fedora Update System 2009-04-15 12:01:42 EDT
msp430-gcc-3.2.3-2.20090210cvs.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/msp430-gcc-3.2.3-2.20090210cvs.fc10
Comment 15 Fedora Update System 2009-04-17 14:02:59 EDT
msp430-gcc-3.2.3-2.20090210cvs.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update msp430-gcc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3721
Comment 16 Fedora Update System 2009-04-21 21:09:58 EDT
msp430-gcc-3.2.3-2.20090210cvs.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.