Bug 485416

Summary: Review Request: msp430-gcc - Cross compiling GNU GCC for the MSP430
Product: [Fedora] Fedora Reporter: Rob Gilton <rob>
Component: Package ReviewAssignee: Steve Whitehouse <swhiteho>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, notting, rc040203, swhiteho
Target Milestone: ---Flags: swhiteho: fedora-review+
kevin: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 3.2.3-2.20090210cvs.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-22 01:10:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
koji ppc64 build.log ending in failure.
none
Diff against *.spec to address the issues mentioned previous comment none

Description Rob Gilton 2009-02-13 14:29:41 UTC
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 Gilton 2009-02-13 14:32:58 UTC
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 14:40:24 UTC
Ok, I'll try and find time to have a look at this over the weekend.

Comment 3 Steve Whitehouse 2009-02-16 19:46:24 UTC
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 Gilton 2009-02-17 14:16:05 UTC
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 14:25:28 UTC
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 16:10:32 UTC
(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 16:12:41 UTC
Created attachment 332240 [details]
Diff against *.spec to address the issues mentioned previous comment

Comment 8 Rob Gilton 2009-02-28 19:44:10 UTC
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 08:30:00 UTC
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 16:57:39 UTC
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 16:01:26 UTC
(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 Gilton 2009-03-26 20:19:16 UTC
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 20:12:40 UTC
cvs done.

Comment 14 Fedora Update System 2009-04-15 16:01:42 UTC
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 18:02:59 UTC
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-22 01:09:58 UTC
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.