Slashdot Mirror
GCC 3.2 Released
bkor forwards the GCC 3.2 release announcement, without attributing it as such: "The GCC 3.2 release is now available, or making its way to,
the GNU FTP sites. The purpose of this release is to provide a stable platform for OS distributors to use building their next OS releases. A
primary objective was to stabilize the C++ ABI; we believe that the interface to the compiler and the C++ standard library are now stable. There are almost no other bug-fixes or improvements in this
compiler, relative to GCC 3.1.1. Be aware that C++ code compiled by GCC 3.2 will not interoperate with code compiled by GCC 3.1.1. More detail about the release is available. Many people contributed to this release -- too many to name here!"
What am I supposed to do with games/commercial software compiled with 2.95.x? Is that not going to work? Someone please enlighten me...
What I'd really like to see is gdb working with GCC3.2. We've been developing with gnu c++ 3.1 here, and 3.1 is much more standards-compliant than, say, 2.96. However, using gdb in conjunction with it is a real headache. Perhaps with this stabilized 3.2 release, there shall come a day when gdb is really useful.
I would intrepet this as saying: If you have say a shared library that was compiled with 3.1.1 and you attempt to use that library with a program compiled with 3.2 then it won't work because the compiled results are not interoperable.
But you can simply recompile both parts using 3.2 and they will work fine. you don't need to change the source code.
I will never live for sake of another man, nor ask another man to live for mine.
How many times is the C++ ABI going to be declared stable before it actually is?
I would have much preferred sticking with 3.1's slightly-broken ABI than 3.2's supposedly-fixed at this point. There's only so many times entire distributions and toolsets can get rebuilt before packagers are fed up.
They also promised that the ABI was finished in 3.0. In fact, that was one of the reasons given for taking so long in getting 3.0 out the door. Not a good track-record, IMHO.
Still, it will be good to get closer to standards-compliance. C++ has been standardized for four years, now, and fully compliant compilers are just now starting to appear. GCC has actually been fairly good compared to some (cough, Microsoft, cough) in adhering to the standard.
Looks like it produces smaller code than 3.1:
.config files.
803130 Aug 15 13:18 vmlinuz
804713 Aug 6 09:08 vmlinuz.old
At least by a tiny bit. Those are both Linux 2.4.19 kernels with the same
call me stupid, I know about API's, but what exactly is an ABI ?????
Does anybody know when GCC wil finally support precompiled headers?
This is really bad timing for Apple folks.
AFAIK, the entirety of Jaguar is compiled with GCC 3.1. Replacing all the libraries with v3.2 is gonna be some mighty huge software updates...
From what Im reading in the comments, there can be problems when upgrading compilers across ABI versions. Can someone either summerize the possible difficulties, or point to a place on the web where I can read about them. What I mean is: If I switch from gcc 2.9x to gcc 3.2, what will I not be able to do, and what problems can I expect
Im not here now... Im out KILLING pepperoni
Finally a stable C++ ABI ???
1. This means that C++ _including objects+classes+ will, with a bit of grunt work, be able to be integrated with real-oo scripting languages just as easily as C - it's the constantly changing C++ ABI that has prevented, until now, "easy" bridging of, say, C++'s object model to Common Lisp's CLOS, without having to recompile everything in sight at the drop of a hat - it will now be possible to produce a C++-to-lisp analogue of, say, CMUCL's excellent "alien:" lisp package (nothing to do with the deb2rpm tool), or SWIG-but-for-proper+C++ for python and perl.
2. It will mean that third-party binary distribution of C++ code is a lot more viable. Remember the way Netscape, Realplayer and flash used to break with every new RedHat release? - well, that was primarily becuase of libstdc++ not linking properly due to changing ABI.
3. This should also mean that the prelink "hack" and it's ld.so-integrated successor can stabilise and become part of standard linux distros - no mare agonisingly slow KDE startup times!
Isn't this rather part of ld(1) (binutils)?
42. Easy. What is 32 + 8 + 2?
If C++ ABI is now declared stable does this
automatically imply that GCC is now fully C++
standards compatible? If not then what is
left to change?
Oh, I got off on a tangent, and didn't answer one of the questions that well.
:)
My friends are the ones who are muscians. They have their own tools and seem to use Windows or just dedicated studio hardware. I mostly make noise, I think they are calling it Intelligent Dance Music this week.
Most of my stuff comes from my head and is performed in code. If I don't like how something sounds I change the code. So I have to do little production work.
I use the inputs on the mixing board (along with it's mic preamps) when I need to aquire something from the analog world. Such as vocals from one of my friends (I have promissed I will not try to sing again).
I divide the vocal sample up into phrases that I can then "render" into the final output.
One thing that is nice, is to render into an 8 channel audio file, seperating vocals or other parts that are very discrete so I can get a rough idea at what levels I should mix each channel using the analog slides. I can just loop the track or selection and sit there and tweak until it sounds good, then look at the values on the sliders to try in a final 2 channel rendering.
So to simply answer you question. I don't sequence or produce in the standard definations of the words.
Oh well who cares about the moderation, I'm talking about something I enjoy.
Use a different prefix! I have 4 different GCC versions on my system (2.96 and 3.0 both provided by RedHat, and 3.1 and 3.2). ../gcc-3.2/configure --prefix=/usr/local/gcc32 [misc unimportant options here]
/usr/local/gcc32. The binaries go to /usr/local/gcc32/bin, the libraries to /usr/local/gcc32/lib, etc. Removing GCC is as easy as rm -Rf /usr/local/gcc32
/usr/bin/gcc32 to /usr/local/gcc32/bin/gcc /usr/local/gcc32/lib to /etc/ld.so.conf and run ldconfig
/usr/local/gcc31) and everything work just fine; no problems whatsoever. I successfully compiled an entire GNOME 2 system using GCC 3.1.
I configure GCC 3.2 like this:
This way, *all* files will be installed in subdirectories inside
To make sure GCC will work:
- make a symlink
- add
I just installed GCC 3.2 an hour ago, but I installed GCC 3.1 using the same method (except that the prefix is
Have all the problems that arose in 3.0 regarding performance on AMD Athlon processors been resolved? memcpy() among other things were quite slow when compared to similar processors with GCC 3, and with GCC 2.95.
Does VC++ have an ABI? Are they all compatible? Could I check by trying to link a VC++6 .lib to a VC++7 .exe?
But now I have to recompile every single C++ library on the system in order to make the new compiler truly useful.
Yet, at the same time, I want to be able to run my old C++ binaries and also want to be able to drop back to my older compiler if necessary.
The best way to accomplish this, I suppose, is to put the new libraries in their own directory and modify gcc 3.2's spec file to include a -L directive to the linker to reference those libraries at link time and a -rpath directive at link time so that the resulting binary references that directory at runtime.
The other options I thought of involve either renaming the libraries (thus requiring manual intervention when compiling any package that would refer to the libraries by their "old" names) or changing their major version number (surely a serious abuse of the purpose of the major number! And it would cause problems when linking using the old compiler anyway). Neither of those are very palatable.
Anyone have better ideas on how to do this?
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Seriously, what makes you think the entire team doesn't already understand this point? Do you think such decisions are made lightly? Go read the archives; they agonized over this for months, and that was before the heavy debating started.
Your explanations make sense, but they don't address an important point. Perhaps I should put on my hip boots and wade thru your archives.
Why are you not deferring ABI changes to major (or relatively major) releases? Why the breakage in 3.1.1? If you find a bug in the ABI, will you break it in 3.2.1 or wait until 3.3 instead?
I'm thinking to myself that a lot of these problems could have been avoided by spitting gcc into a stable and a devel branch.
A Government Is a Body of People, Usually Notably Ungoverned