Subj : Re: Sharing code between BC5.02 and BCB5
To   : borland.public.cpp.borlandcpp
From : "Ed Mulroy [TeamB]" <dont_email_me@bitbuc.ket>
Date : Wed Mar 03 2004 02:19 pm

The exported symbol name must exactly match the imported symbol name.  The
designer of the linker arranged for it to show you the information for both
in the hopes that it would assist you in deciding how to proceed in
correcting the errors.

A standalone function not part of a class has the same default calling
conventions in C or C++.  The only difference is the name mangling that C++
uses, a method which is used to implement the C++ ability to have overloaded
functions.

The correct way to do what you ask is to build the DLL with the BCB compiler
so that the names match and then alter the header files so that they no
longer lie.

Failing that you could use place an alias into a module definition file to
provide an alternative name for the function.  For example:

  ----contents of DomeName.DEF -----
  IMPORTS
      _NameUsedByTheExeFile = DLLNAME@FuncName$qv
  -----------------------------------------

You then add the module definition file to the project.

..  Ed

> Dennis Jones wrote in message
> news:404612ad$1@newsgroups.borland.com...
>
> I have a large number of old DLL projects that I inherited
> which were written with Borland C++ 5.0, using OWL.  I
> have converted many of those projects to BCB 5 w/VCL.
> However, several of them still remain BC5 w/OWL
> simply because of lack of time.
>
> The OWL-based DLL's export functions that are callable
> by the other DLL's. However, the functions are all exported
> as 'extern "C"', which means that much of the C++ type-
> checking is eliminated.  I have discovered numerous
> cases in the old DLL's where the function prototypes did not
> match the actual function definitions, and yet the code still
> compiles and runs.  I decided it would be worthwhile to
> remove the 'extern "C"' declarations to take advantage of
> C++ type-checking for the function prototypes to hopefully
> catch all such errors.  However, in doing so, I have lost the
> ability to link between the BCB DLL's and the BC++ DLL's.
>
> The functions are being exported with name-mangling (which
> is identifiable by each function's name and parameter types
> being listed in TDUMP's output, rather than a simple fiunction
> name prepended by an underscore, as is the case for a
> function declared with 'extern "C"'), and yet the linker's
> "unresolved external" complaints exactly match the exported
> function names!
>
> Has anyone an idea why, though the linker complaints match
> the exported names, the linker still fails to resolve the external
> references?

.