delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/12/09/16:05:10

From: michael DOT mauch AT gmx DOT de (Michael Mauch)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Changing from C to C++
Date: Tue, 09 Dec 1997 09:10:48 +0100
Organization: Gerhard-Mercator-Universitaet -GH- Duisburg
Lines: 39
Message-ID: <348c947f.5283597@news.uni-duisburg.de>
References: <2mgLUAAHZHj0Ewld AT timehigh DOT demon DOT co DOT uk>
NNTP-Posting-Host: ppp100.uni-duisburg.de
Mime-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On Mon, 8 Dec 1997 22:35:51 +0000, Caroline Langensiepen
<caroline AT timehigh DOT demon DOT co DOT uk> wrote:

> extern void SVAsyncProtISR(void);
[...]
> 4. Trying to be too clever, I changed the extern reference to
> extern SVAsyncProtISR;

I guess that makes SVAsyncProtISR an int...

> This keeps ld happy, all refs are resolved, but the code crashes with
> protection error, suggesting I've probably not got the right ref to the
> ISR address!

Linking C and C++ modules gives unresolved externals because of the
name-mangling that is done for C++ function names. Remember that in C++
you can have two or more overloaded functions, i.e. functions with the
same name but different parameters. So to avoid name clashes in the
linking process, the compiler names the function(int) "_function__Fi"
and the function(char*) "_function__Fpc". A C function() with or without
any parameters will always be named "_function" by the compiler.

To resolve these problems, surround your C headers with

#ifdef __cplusplus
extern "C" {
#endif

[your prototypes go here]

#ifdef __cplusplus
}
#endif

This makes that the compiler tell the linker that it has to search for a
_SVAsyncProtISR, not a _SVAsyncProtISR__Fi or whatever.

Regards...
		Michael

- Raw text -


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