Dumb Symantec C++ question

Ok, I've wasted two days trying to figure this out.

I'm stuck using Symantec C++ 7.5 on this one project.
I'd port it over to something more recent, but time is pressing...

I need to move some functions out to another file,
compile them separately, then link the whole shebang back together.

Good old C++ name mangling is getting in the way.


I tried "_cdecl" in the function bodies, the compiler accepts it, but no go,
names still are mangled.

I tried "extern "C"" in the declarations, this seems to work.

But I still can't export the actual code with the simple unmangled name!

Of course the Symantec C on-line help doesnt even mention _cdecl
or anythijng similar.

Any hints appreciated!!

re: Dumb Symantec C++ question

Can you be more specific about what you are trying to do ? If both files
are being compiled with C++, then the linker should have no problem.
Provide some more details and I should be able to help you out. Provide the
function signatures and file names.


"George R. Gonzalez" <grg@umn.edu> wrote in message
news:bjt30t$io2$1@lenny.tc.umn.edu...[color=blue]
> Ok, I've wasted two days trying to figure this out.
>
> I'm stuck using Symantec C++ 7.5 on this one project.
> I'd port it over to something more recent, but time is pressing...
>
> I need to move some functions out to another file,
> compile them separately, then link the whole shebang back together.
>
> Good old C++ name mangling is getting in the way.
>
>
> I tried "_cdecl" in the function bodies, the compiler accepts it, but no[/color]
go,[color=blue]
> names still are mangled.
>
> I tried "extern "C"" in the declarations, this seems to work.
>
> But I still can't export the actual code with the simple unmangled name!
>
> Of course the Symantec C on-line help doesnt even mention _cdecl
> or anythijng similar.
>
> Any hints appreciated!!
>
>[/color]

re: Dumb Symantec C++ question

Kris Wempa wrote:
[color=blue]
> Can you be more specific about what you are trying to do ?[/color]

Please don't top-post. Re-read section 5 of the FAQ for posting guidelines.

http://www.parashift.com/c++-faq-lite/

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: Dumb Symantec C++ question

Ok, I didnt describe things too clearly the first time.

The problem is this program is calling a few functions that normally live in
a DLL

Those functions havent a chance of running on MY PC, as they expect some
really weird I/O box plugged into the bus.

Soooo, I want to write some little stubs that print out: "OSC_FREQ called
with param: ####", and so on.

The functions are normally declared as : extern "C" VB_CODE FAR PASCAL
OSC_FREQ( yadda, ... );

I have my stubs declared as: extern "C" VB_CODE OSC_FREQ( yadda, ... );

(This generates a call to _OSC_FREQ() )


( "VB_CODE" is a enum type )

In my separate file of stubs, how the heck do I declare the functions?

As I've noted, this brain-dead compiler accepts and IGNORES "cdecl"
"_cdecl", .. Ick.


Thanks,

George

re: Dumb Symantec C++ question

George R. Gonzalez wrote:
[color=blue]
> Ok, I didnt describe things too clearly the first time.
>
> The problem is this program is calling a few functions that normally live in
> a DLL
>[/color]

I kind of suspected this would deal with DLLs. I'm afraid you are on the
wrong group. Try a Windows programming group. This group only discusses
the Standard C++ language, which does not include DLLs. Please read the
welcome message for a list of groups you might try, as well as
information about topicality in comp.lang.c++:

http://www.slack.net/~shiva/welcome.txt

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: Dumb Symantec C++ question

George R. Gonzalez wrote:[color=blue]
> Good old C++ name mangling is getting in the way.
>
> I tried "_cdecl" in the function bodies, the compiler accepts it, but no go,
> names still are mangled.
>
> I tried "extern "C"" in the declarations, this seems to work.[/color]


I don't know symantec (this is the wrong newsgroup). But I've seen
linkage problems :-). The following has worked wonders after stupid
mistakes,
% rm *.o
% make
That is, delete all object files and build everything from scratch.

Or, to see what symbols are actually present present in an object file,
% nm -a foo.o
Ideally, the symbol in question gets defined in exactly one object, and
you have it undefined in zero or more other files.

You might get more specific help here if you posted a minimal compilable
code that exhibits the problem. Or you could try a more focused group;
I see, e.g.,
symantec.support.devtools.mac.sc++.announce
symantec.support.devtools.mac.sc++.environment
symantec.support.devtools.mac.sc++.programmer
symantec.support.devtools.pc.sc++

Christian

re: Dumb Symantec C++ question

"George R. Gonzalez" <grg@umn.edu> wrote in message
news:bjtbcg$lcn$1@lenny.tc.umn.edu...[color=blue]
> The problem is this program is calling a few functions that normally live[/color]
in[color=blue]
> a DLL
>
> Those functions havent a chance of running on MY PC, as they expect some
> really weird I/O box plugged into the bus.
>
> Soooo, I want to write some little stubs that print out: "OSC_FREQ called
> with param: ####", and so on.
>
> The functions are normally declared as : extern "C" VB_CODE FAR PASCAL
> OSC_FREQ( yadda, ... );[/color]

Far pascal? Does that mean your DLL is written in 16 bit code? If so, you
cannot connect to 16 bit code using a 32 bit memory model. You'll need to
use a 16 bit memory model. If that is the case, a declaration that is likely
to work would be:

extern "C" VB_CODE __far __pascal OSC_FREQ(yadda, ...);
[color=blue]
> I have my stubs declared as: extern "C" VB_CODE OSC_FREQ( yadda, ... );
>
> (This generates a call to _OSC_FREQ() )
>
>
> ( "VB_CODE" is a enum type )
>
> In my separate file of stubs, how the heck do I declare the functions?
>
> As I've noted, this brain-dead compiler accepts and IGNORES "cdecl"
> "_cdecl", .. Ick.[/color]

If you want to check the names produced by the compiler, run OBJ2ASM over
the resulting .obj file. But it looks to me like you'll need to declare it
as __far __pascal, not __cdecl. I don't think it is ignoring __cdecl, as
_OSC_FREQ is the correct C name mangling (which is prepending an "_").