Re: Newbie: Patching gcc, libstdc++ build problems

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

 



I can understand gcc_3_1_1,_release, names, but what if it says branch, or
ssa something, something, or merge, something something?  I see lots of
patch information on the patch lists, but I assumed that someone checked the
patch into CVS at sometime.  If thats a valid assumption, I'd like to know
how to determine into which tag level that a particular patch went.  That
said, I tested one of the patches, by hand, and it didn't fix my problem, so
I guess I'm barking up a wrong tree.

As far as 3.3.1 goes, I'm sure that's just great and dandy.  I'd even like
to use it, except that my hands are tied for support reasons.  Internally,
if I don't build our package with gcc 3.1 and the XML package that it uses
fails, we can't expect to get help from the people (also internal) who built
the XML package.

Thanks
Ben Pracht

"Eljay Love-Jensen" <eljay@xxxxxxxxx> wrote in message
news:5.2.1.1.0.20031014212749.018a7b80@xxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Ben,
>
> As I understand it, the "gcc-3_1_1_release" tag is the GCC 3.1.1 with all
the patches that make GCC 3.1.1 ... well ... GCC 3.1.1.
>
> If you want patches that have been applied since to, say, GCC 3.2.3,
you'll have to diff GCC 3.1.1 vs 3.2.3 and apply them yourself.  After all,
GCC 3.1.1 is "stick a fork in it it's done", fully cooked, out the door,
shipping party, everyone gets drunk, regret their silly antics from the
night before, best forgotten, ahem, what about them NY Yankees?
>
> HTH,
> --Eljay
>
> PS: What's wrong with GCC 3.3.1?
>
>
>




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux