Slashdot Mirror
GCC-2.95 in July
Bananenrepublik writes "On this page, the EGCS steering committee has posted the official schedule for the transition from egcs to gcc-2.95. So expect gcc-2.95 in early July. " It looks pretty aggressive. I wish the team luck, and eagerly await the improved compiler.
Strip only removes symbols. This sounds like there is unnecessary object code being included.
gcc now stands for the GNU Compiler Collection,
not the GNU C Compiler for precisely this reason.
Using gcs and egcs was considered, but "gcc" was
selected as the best name.
Jeff
OK, more detail is in order. Using a bunch of libraries, but only bits and pieces from each gcc yields are large static binary. If I cut and paste the bits and just link in those the binary is much smaller. If I use shared libraries the binary is much smaller, but after the dynamic link at run time it is just as big in memory.
In the M$ case there is no significant increase in size with the non cut and paste version. The linker seems to only grab what it needs.
I use -O and strip afterwards for these tests.
Dont misunderstand...I use dynamic libraries usually, but certain customers prefer static binaries and are concerned with the size. Also, I push UNIX (although not always Linux, SMP isnt there yet compared to IRIX and Solaris) over Win32, but again some customers are just mired in their Win32edness.
The current EGCS snapshots have some support for the new C standard ( C9X) . But well... it is just a beginning and a lot of basic C9X features are missing (the Glibc2.1 misses many C9X functions, too, especially with wide chars concerns) . I hope GCC 2.95 will finally have all the features of the final comitee draft. As that standard will soon officially replace the current C language definition, GCC have to follow it. Having a decent C9X compiler on Linux is the best way of learning properly the new C language revision.
(1) If there is something called "Cygnus Inc" it has nothing to do with Gcc. The name you are looking for is "Cygnus Solutions". If you want to be informal, you can say "Cygnus" - but don't add "Inc"; if you add "Inc", get the name right. (While "Cygnus Solutions" is looking for a new company name, I don't think one has been chosen yet.)
(2) Cygnus is *not* the maintainer of Gcc. The maintainer of Gcc is the Egcs steering committee. The steering committee contains individuals, but no companies are members. Some of the steering committee members are Cygnus employees, including the technical manager (I forget his official title), Jeff Law. Other members belong to other organizations.
While this is not an official statement, I am a member of the Egcs steering committee, and (until next Wednesday) a Cygnus employee.
I believe it is important to clear up a few issues
that have come up on this thread:
1. It's Cygnus Solutions, not Cygnus Inc. At
least until our name is changed.
2. Cygnus contributes to egcs, but does not
control egcs. egcs is controlled by the
egcs steering committee which includes
people from a variety of different backgrounds.
http://egcs.cygnus.com/steering.html
It is important to realize that while Cygnus
does have representation on the egcs steering
committee, it does not have a majority on the
egcs steering committee.
3. The egcs project was already in the process of
putting a release together. It was originally
to be called egcs-1.2. However with the
egcs/fsf merger we decided to rename the
release gcc-2.95. So July may not be as
aggressive as one might think.
4. The development model of egcs is not changing.
Some changes will be necessary as part of the
egcs/fsf merger, but the basic development
model used by egcs will not be changing.
Jeff Law
Cygnus Solutions
egcs project
I think they made it quite a bit stricter on some inline asm things, which broke some parts of the kernel. pre-2.2 kernels has "DO NOT COMPILE WITH EGCS" all over em or something :)
-Yarn - Rio Karma: Excellent
I could be wrong, but doesn't 'strip' just take out debugging information? I don't think it takes out unused functions/variables. That's called 'smart linking'. Borland's DOS compilers have had them for AGES. Why doesn't the GNU linker???
When is libstdc++ going to implement ostringstream??? I'm getting tired of using ostrstream...
As someone else pointed out already, try running strip on the binary, or compile with -s which does the same thing.
Also, I think that a lot of Windows code is shared DLL's no matter how you link it, so there might be an apples to oranges comparison here depending on what type of application you're building.
(Sorry if this posts twice, I hit the return by accident)
I was wondering if anyone knows where there is a good overview of the *nix C++ compiler variants and their implementations of the standard. I haven't had much time to keep up with the latest and greatest compiler versions, and am now woefully out of date.
Any help is appreciated.
-Tim
Let's try not to let fact interfere with our speculation here, OK?
I think that you meant 331372 bytes and 3296 bytes.
Take a look at
http://www.cco.caltech.edu/~ja fl/jx/egcs_complain.html
John_Chalisque
I was wondering if someone could clarify a few points for me about PGCC, EGCS soon to be GCC-2.9.....
1) What is the connection between PGCC and EGCS. I know that PGCC is based on the EGCS code and that the improvements from PGCC are rolled back into the EGCS code base, but how do the two compare on producing optimized code for Pentium/PentiumII machines. Does PGCC have code that doesn't go back into EGCS or does, for example, EGCS 1.1.2 have all the improvements from PGCC 1.1.1 in it?
2) Has anybody done any basic benchmarking of the two ??
If anybody has any answers... then please enlighten me
P.S Yes, i know this isn't a mailing list or bulletin board, and the questions are slightly off topic, but please indulge me !!!
Iggy
That's autoconf, not egcs.
Why fix it? The GNU refers to glibc, as Linux is only a KERNEL. It will not say "gnu" if you use libc5 or libc4, or write your own for example.
C++ hello world linked with just libc: 3296 k
almost 4 meg for "Hello World"? That's just... incredible.
Try strip -s
EGCS put gcc on speed :-)
what sort of awful thing did egcs do to gcc?
I've finally had it: until slashdot gets article moderation, I am not coming back.
Ever use the strip command on that static binary?
Hi, I'm the coordinator of the Free Trek project (see web site above) and our game is portable betwen Linux and Windows (and Solaris and other UNIX too with little trouble).
I use MSVC++ 6.0 for the Windows port, but wish I didn't have to. If you need to use the Standard Template Library, you're only hope to compile is to get STLPort (www.stlport.org) and cross your fingers. Debugging that crap is horrible because the error messages are completely un-helpful.
Microsoft has a long way to go before their development tools are enterprise ready.
If tits were wings it'd be flying around.
If that's a "transgression", uh, well, I don't quite know what to say.
Hopefully, within a few years, somebody will implement the f*cking standard, especially WRT templates.
We need an industry-wide organization to require vendors to prominently display the following information:
"Our Fucking Compiler is Broken in the Following Ways:
Like, truth in advertising or something.
If I may go charging blindly off-topic, does anybody know offhand how badly broken MSVC 6 is with templates? v5 is a mess, but I'm hoping that with 6 they took a break from adding useless bells'n'whistles to the IDE (and removing useful ones from the help system), and put a couple of guys on fixing the compiler for a week or so. We don't have v6 at work because we don't use templates that much, and we're too busy to "take advantage of productivity features". I mean, "productivity" is great if you've got a lot of time on your hands, but we have to ship stuff so we just write code instead. We've already got our hands full avoiding the "productivity features" in v5. The last thing we need is more of them.
v5 seems to have a few quirks with resolving overloaded functions in derived classes, too. Or maybe it was my own error, mixing overloads and virtuals. Aarrgghh.
"Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"
"Christianity neither is, nor ever was a part of the common law." --
I use MSVC++ 6.0 for the Windows port, but wish I didn't have to. If you need to use the Standard Template Library, you're only hope to compile . .
Oh, lord. Is it that their STL implementation (Dinkum?) is broken, or the compiler's template implementation breaks a good STL implementation, or is it just incompatible with older versions? I can't think offhand of any MSVC 5 template problems that require you to write code that would break in a good implementation, but I'm far from an expert on templates.
I seem to recall reading that the ANSI STL differs enough from previous versions to be a problem -- or in other words, we're in a transitional period when the Standard (capital 'S') is non-standard (small 's'). So to speak.
Damn, I use the STL a lot. I don't do anything arcane or clever with it, but I do use it.
Microsoft has a long way to go before their development tools are enterprise ready.
:)
Unfortunately, they don't often seem to be going in the right direction. I read an intervew with the guy in charge of that project. He's a total pod person. Nine out of ten of his answers mentioned either "innovation" or "all the great features of Windows". I mean, verbatim, "all the great features of Windows", that exact phrase, over and over. He also thought that portability was a waste of time, because most developers only have one computer on their desks anyway (maybe that's not precisely what he meant, but it looked like that was what he was getting at and I was too horrified by then to pay close attention). Like all things that Microsoft people say, it made me unspeakably depressed for several days after reading it.
"Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"
"Christianity neither is, nor ever was a part of the common law." --
The main one I have noticed was that they managed to break some system DLLs like MSVCRT.DLL.
Um, yeah, I may have heard something like that . . . Or maybe i heard about an entirely different instance of them breaking system dll's.
the breakage (changes in the behavior of malloc/free)
What kind of changes?
MSVC++ 6.0 SP2 seems to fix that problem . .
What SP are they up to by now? IIRC SP2 was this winter, for a product released around October or something. Wow.
using cut-and-paste while debugging crashes the debugger
To be fair, that's just the IDE, not the compiler -- but it's still hilarious. MSVC6 is supposed to let you edit and recompile on the fly while debugging, isn't it? That almost sounds useful.
"Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"
"Christianity neither is, nor ever was a part of the common law." --
Um, what don't you like about gcc?
What do you like about MSVC?
Failing that, can you at least name some things which in your opinion might make one compiler better than another?
I mean, I've used both and for most of my purposes I don't see much difference, except that cl.exe knows to name the executable after the file with main() in it, but with gcc I have to tell it "-o exename". I hope you don't think that's a major issue. Innocent and poetic soul that I am, I don't pay much attention to the size of the executables these things barf up.
Or are you just rattling people's cages? If so, you can do better, I'm sure. Try gun control. That's always a good one. Here's an example:
"GCC was obviously designed by a whining, socialist liberal gun-control advocate. That's why it doesn't support namespaces: Because the liberals want to force us all to live together and be equal."
:)
"Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"
"Christianity neither is, nor ever was a part of the common law." --
Why don't you use the CygWin port (it includes egcs) for Win32?
Mmm, yeah, egcs does namespaces, which mingw32 (or at least the version I have) does not.
mingw32, if you haven't run into it, is yet another win32 port, which uses the MS c runtime which comes with windows. I don't have the URL handy. Last I looked at the page (months ago) there was some kind of talk there about folding egcs into it.
Anyhow, I do have cygwin at work, but I haven't bothered at home (the difference is the T1
But why do I still use MSVC for my own stuff? Well, I like to make sure things are portable. I try to make everything compile with both gcc and MSVC. I also like MSVC's text editor. I just do, deal with it
"Once a solution is found, a compatibility problem becomes indescribably boring because it has only... practical importance"
"Christianity neither is, nor ever was a part of the common law." --
And who really cares all that much about the size of static binaries? If you're compiling static binaries, size obviously isn't a big concern.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Try 'gcc source.f' or any other . supported by the compiler collection.
It compiles all of them, with the right front end. So 'gcc' doesn't mean 'C compiler' and hasn't for a long long time.
TA
As far as I've read, the development will continue in much the same way as has been done with egcs.
It seems to me that it is library organization problem rather than a linker problem. After all, the linker do just the simplest thing: get in object, find all unresolved symbols, jam in all objects that provides any of the unresolved symbols and repeat. It seems to me that the library contains too much inter-dependencies, which cause most of the library object files to be included into the final binary. Can anybody confirm or disprove this?
/lib/libc-*
By the way, I cannot reproduce the results shown in other posts. My hello world compilation gives 89k stripped static binary and 3k stripped shared binary. Here's what I used:
> g++ --version
egcs-2.91.60
> ls
/lib/libc-2.0.7.so
The system is a Debian slink system, by the way.
There's GNU make for win32 (cygnus or mingw32 tools)...
I target both win32 and linux... I *do* love the msvc6 editor... so I use that, but build from the command prompt...
I am not a guru, but I have experienced the same situation observed with the linking of static libraries. It's amazing to me this information isn't more widely known -- perhaps it's obvious to the gurus and therefore never written down, but that doesn't help the rest of us.
KEY PIECE OF 'SECRET' KNOWLEDGE: The GNU linker is designed to be used with 1 global object per object file.
You can produce object files with lots of global objects, but they won't be linked intelligently beyond the first one.
I define intelligent linking as including the object in the executable only if it is needed.
The GNU linker only applies intelligence to the first global object per object file, and any global objects beyond that just get thrown into the executable regardless of whether they are needed or not. The actual rule might be slightly different from my observation, but the idea that only the first global object is treated intelligently is definitely true. That is how you end up with the enormous Hello World program.
A global object is defined as something like a function or a global variable. This is why you see many professional libraries composed of many tiny source files -- 1 function per file.
What I don't know is how to extend this concept to C++ -- is the global object the member function or the class itself? Do you have to split up the member functions into separate files? And don't even try to ask me how to put specialization of a template function into a library.
In summary the poster does have a valid point: Visual C++ has no limitations about 1 global object per object file, and therefore is a much more flexible tool for someone who is creating a static library.
I'm not impressed that in all the noise generated not a single person had anything of substance to say about his comment.