A Portable C Compiler

[jacob navia]

Since I killfiled Mr Navia, people have stopped complaining at me for
arguing with him all the time. I am not ungrateful for this. I have
noticed, however, a marked increase in the rate with which *other people*
are arguing with him.

Sniff, sniff....

 

[jacob navia]

I suspect the project Jacob is talking about is actually mostly C++.

Yes, as I said the company uses C++

Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.

The linker is VERY slow, and that hits you even when doing
a trivial change.

 

[Charlie Gordon]

To me, the requirement for such a long routine compile indicates
mis-organization. Normally you would only be modifying one source
file, and the rebuild should be limited to recompiling that and
relinking. Sometimes the associated .h file may need revision, and
then (rarely) the work can become considerably larger. So in
general the compilation should not be a problem, however the
linking may be.

I suspect the project Jacob is talking about is actually mostly C++.

Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.

 

[user923005]

Yes, as I said the company uses C++


The linker is VERY slow, and that hits you even when doing
a trivial change.

GCC is totally irrelevant as far as linking is concerned. The speed
of linking for PCC or any other compiler will not be any different at
all, since both PCC and GCC are going to perform exactly the same link
step using exactly the same linker. The link step is performed by the
operating system's linker, and so the speed of the link won't change
at all unless a compiler vendor supplies its own linker. Microsoft
does that, but then again, they also wrote the operating system for
their compiler so no great surprise there.

I believe that this has all been explained to you before. I think
that you are deliberately being thick here.

 

[Richard Heathfield]

user923005 said:

The linker is VERY slow, and that hits you even when doing
a trivial change.

GCC is totally irrelevant as far as linking is concerned. [...]

I believe that this has all been explained to you before. I think
that you are deliberately being thick here.

Hanlon's Razor applies.

 

[Richard]

Gee, do you reckon? Jacob's whole modus operandi in this group is to be
completely unreasonable, get people really riled up, and then when they
react he plays the victim - "everyone's picking on me!"

That is not what I have seen.

Look at this thread. It serves absolutely no purpose except for Jacob to
spread a load of FUD about gcc.

Jacob obviously thinks the world owes him a living because he took
someone else's compiler, knocked up a pretty GUI IDE to go with it, and
repackaged it as a commercial product. It's clear from his postings to
this group over several years that he doesn't have the first beginnings
of a clue about C - he's not just a social pariah, he's technically
inept to go with it.

Hmm. I see a certain pattern emerging in your style.

This group would be a better place if Jacob would stop posting to it and
leave us all in peace.

Who is "us"?

 

[jacob navia]

GCC is totally irrelevant as far as linking is concerned. The speed
of linking for PCC or any other compiler will not be any different at
all, since both PCC and GCC are going to perform exactly the same link
step using exactly the same linker.

If they do that, it would be really stupid.
The linker of GNU is very slow.

But I am not saying that GCC is responsible for the flaws of ld,
even if is in the same tool chain. It was just a remark about the
speed of the link step.

The internal structure of that linker is quite involved, doing several
passes to find constructors, then putting them in an automatically
generated C file, then compiling that (yes, they compile C code
within the link step!!) and then (and only THEN) linking the whole
mess.

The speed of gcc *is* important within the linker since the
linker compiles C code when linking.



I was completely surprised when I discovered that.

The link step is performed by the
operating system's linker, and so the speed of the link won't change
at all unless a compiler vendor supplies its own linker. Microsoft
does that, but then again, they also wrote the operating system for
their compiler so no great surprise there.

The OS supplies no linker under windows, That's why I had to write one.

I believe that this has all been explained to you before. I think
that you are deliberately being thick here.

You take a remark as "ld is slow" and just suppose that I am blaming
gcc. No I am not. But... see above

 

[Charlie Gordon]

Yes, as I said the company uses C++


The linker is VERY slow, and that hits you even when doing
a trivial change.

Your digression on compile times is completely irrelevant to C.
I'm not saying gcc is fast, tinycc is *much* faster and includes the linking
phase too, but your example is irrelevant. C++ projects take a toll on
developpers ? We all know that, we prefer C.

For those who care about build speed, there is a very effective tool called
ccache.

 

[Peter J. Holzer]

Woah, 10 minutes of *linking* ? I think it's time you investigate making
your build system suck less.

I've seen link times in excess of an hour for reasonably-sized programs
(OpenSSH in this case). The +O4 option on the HP ANSI-C compiler causes
global optimization on the whole executable, which can of course only be
done at link time. Of course nobody would use +O4 on an HP system during
the normal edit-compile-test cycle. That's strictly for release
candidates (unless you are looking for a bug which only manifests itself
at that optimization level).

hp