X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
References: <76F97D29CEDF4D97BA3004F2C2B2EF08 AT desktop2> <f850us$2h1$1 AT sea DOT gmane DOT org> <FCAC8B1EEB2D47EB8D55FB8C2C7A0774 AT desktop2> <46A65A46 DOT 80209 AT x-ray DOT at>
Subject: RE: Trying to build (perl) Inline::CPP-0.25.
Date: Tue, 24 Jul 2007 23:15:32 +0100
Message-ID: <021801c7ce40$26e74cf0$2e08a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <46A65A46.80209@x-ray.at>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 24 July 2007 21:00, Reini Urban wrote:


> Switching to g++ probably has other issues. Most XS modules are pretty
> fine with gcc, but I wouldn't be sure if all of them are C++ safe.

  This isn't an issue, or rather, it's not as bad as you think.  Whether you
use g++ or gcc as the driver, it still looks at the file extension to decide
what language subcompiler to invoke; the only real difference between the two
is in the -I, -D and -L options they assume by default.  There could be
namespace clashes with C++ headers that don't exist in C, and there could
perhaps be issues in linking against libstdc++ and libsupc++ (name mangling
would protect against most accidental collisions here, but I don't know if
there might be extern "C" functions in either of them), but you would't need
to worry about the language incompatibilities.
 
> For the start having a wrapper should help use in fixing this inside
> ld2 or perlld.
> We should detect if the intermediate .o was compiled as c++ or plain gcc.
> nm -C $obj|grep "operator new(" for example. Is there a better way?

  I'm not sure this is necessary (particularly in light of the above).
Whatever you do should work if the final executable combines C *and* C++
modules, without causing complications for the C, so it should work for a
final executable that only has plain C modules as a special case.  I think you
should be just able to use g++ for the link step regardless, and need only
trouble yourself with picking the right driver for the compilation step.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/