delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1997/12/15/10:40:36

Date: Mon, 15 Dec 1997 17:40:17 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc: djgpp workers list <djgpp-workers AT delorie DOT com>
Subject: Re: Trouble with C++ and interrupt (fwd)
In-Reply-To: <Pine.LNX.3.93.971215161122.9550A-100000@acp3bf>
Message-ID: <Pine.SUN.3.91.971215173634.23767A-100000@is>
MIME-Version: 1.0

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
> multi-file ones, and so they usually won't be compiled and linked in one
> go, but instead the linker run will be passed a list of .o files only,
> which are indistinguishable from compiled C (or F77, or Pascal, or
> whatever) files.

I think it will work as long as they compile and link the .cc files in 
one step.  If they call gcc to link .o files, then of course it won't 
work.  However, I doubt that people who ask these questions are aware of 
the separate compile/link steps.

> 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?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019