There isn't really an overview of how it's done.  I don't know how the
previous maintainers did it; I have git repositories for binutils, gcc, and
gdb, where I maintain branches that have all the patches applied, and use
them to generate the patches that are added to the mspgcc4 distribution.  I
have not made those repositories available, except for binutils, because
they're a mess and I don't want to support them.

A slightly more evolved version of the same scheme is done with the git
repositories that are now available on the mspgcc project, which are about
to supersede mspgcc4.  For those I will not be providing packaging scripts
like mspgcc4, which as you note are very inconvenient for people to modify.
My hope is that this will convince people to take on the responsibility to
build distributions for known platforms.  (Also, I don't intend to make
changes to support insight, though somebody else is welcome to take that
on.  The current version of gdb will be supported.)

As far as the current problem is concerned, the change to support the
upstream interface change has been moved from the version-independent gdb
code to the version-specific gdb patch, and will be in the next release.
Which I'm testing tonight.

Peter

From: Albert ARIBAUD <[email protected]>
> Date: Sun, Feb 13, 2011 at 1:29 AM
> Subject: Re: [Mspgcc-users] mspgcc4 version 20110130 released
> To: [email protected]
>
>
> Le 13/02/2011 04:34, Mark J. Blair a écrit :
> >
> > On Jan 31, 2011, at 11:42 AM, Peter Bigot wrote:
> >> How many people depend on insight?  I was under the impression it wasn't
> >> used much.
> >
> > Sorry, I'm a couple weeks late to the party!
> >
> > I don't depend on Insight at all, simply because I haven't been able to
> compile it on my system (Mac OS X) yet. I'd give it a try if I could build
> it. ;)
>
> Don't feel alone: I can't either, on a 64-bit Ubuntu, but the same holds
> true for all I believe: If I'm not mistaken, the GDB and Insight sources
> usable in the latest MSPGCC4 release are mutually incompatible, due at
> least to a minor difference between argument qualifiers in a function
> prototype.
>
> I would like to offer a patch but I am not sure how to proceed, because
> I don't have a clear idea yet of exactly how MSPGCC4 is built; it seems
> that actually it is provided as patches against the pristine gcc and
> binutil sources, so in order to test that my fix works I would need to
> 'back-patch' the fix into the patch files, but I don't know how to
> regenerate those properly -- or even if I understood the process at all,
> to be honest. :)
>
> Is there an overview of the development of MSPGCC4?
>
> Amicalement,
> --
> Albert.
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
> ---------- Forwarded message ----------
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to