Date: Mon, 15 Dec 1997 17:09:54 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp workers list <djgpp-workers AT delorie DOT com>
Subject: Re: Trouble with C++ and interrupt (fwd)
In-Reply-To: <Pine.SUN.3.91.971215173634.23767A-100000@is>
Message-ID: <Pine.LNX.3.93.971215164807.9550C-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk

On Mon, 15 Dec 1997, Eli Zaretskii wrote:
> On Mon, 15 Dec 1997, Hans-Bernhard Broeker wrote:
> > > It seems that something like %{.cc: -lstdcxx -liostream} (and the same
> > > for other C++ suffixes) in the "*link_command:" section should do the
> > > job.
> > Sorry, but it almost certainly won't, as most C++ programs will be

> I think it will work as long as they compile and link the .cc files in 
> one step.  

Of course, it will. 

> If they call gcc to link .o files, then of course it won't 
> work.  

That's exactly why I doubt it'll gain us anything in the end.

> However, I doubt that people who ask these questions are aware of 
> the separate compile/link steps.

They may not be, yes. The trick would just stop forcing them to learn
about it early. But that would mean that they'ld have right the same
problem they throw at us now; it'd only occur two lessons later in their
course of 'teaching myself C++'. The surprise would be even worse than it
currently seems to be. I can already imagine them screaming out in the
newsgroup, like this:

---- clip: possible future posting to c.o.m.djdpp ----
	Subject: gcc can't do multiple source files

	What the bloody hell is this? As told by my C++ course book,
        I just split up my program in two source files, and suddenly
        it starts complaining about 'undefined reference to cout::...'
	Obviously, DJGPP can't compile multifile projects. In other
        words: it's completely useless        
        [some more confused ranting would follow...]
----- clip end -------------

I don't think we want this any more than we want the current situation. 

> > I doubt there's any real way against this
> 
> If worse comes to worst, we can make gcc *always* scan these libraries.  
> After all, that is probably what BC and the like do, no?

I'm not too sure. I'd guess the word 'integrated' in 'IDE' is the real
trick, instead: From the project description it gets, the IDE does know
that this program is a C++ one, and can thus add the necessary flags
behind the scenes. At least, that's what I seem to remember having read in
some newsgroup: As soon as you start using BC's 'make' and command line
compiler, you also have to provide things like the dreaded '-lm' and so,
and I guess the C++ libs fall under this rule as well.

Neither make nor gcc know the source language of an .o file, so they can't
work this magic. If at all, we'ld have to find a way to detect C++ .o
files *during* the linking stage, and add the standard C++ libs to the
link if we find any of them, probably with a notice.

So the real question would be: can we do this in a linker script, or may
we have to dig into the ld sources to do this? 

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.