C name mangling driving me crazy :-(

[p.f.moore]

I'm having huge trouble getting my plugin to link correctly. The code
is C, not C++ - I can compile it as C++, but it does not use any C++
features, and I'd rather not use C++ unless I have to.

The problem lies in the C name mangling (_function@N), which I cannot
seem to get to work sanely. Part of the problem is that the SDK only
supplies a C++-compatible import library for TakeCmd.dll. However, I
can generate an appropriate (maybe!) .lib based on MS KB entry 131313.

I'm using MS C++ 2008 Express Edition. My sources are compiled using
cl /c lua.c. For my link, I am doing

link /out:lua.dll /DLL *.obj TakeCmd.lib

DLL has an export table that looks like this:

ordinal hint RVA name

1 0 00001020 _GetPluginInfo@0
2 1 00001090 _InitializePlugin@0
3 2 000010B0 _ShutdownPlugin@4
4 3 00001550 __lua_release@4
5 4 00001520 __lua_version@4
6 5 00001260 _f_lua@4
7 6 00001580 _lua@4

When I try to load the plugin, I get

>plugin /L Lua

TCC: (Sys) The specified procedure could not be found.
"Lua"

OK, what procedure???!? If I use a .def file to get names without the
initial underscore or terminating @N, it makes no difference. If I use
gcc, I get a .dll with *both* names in the export table, and the
plugin loads OK. I'm baffled as to why.

I've tried all sorts of combinations and variations, with different
results which, quite frankly, I cannot explain.

To a large extent, I'm tempted to ignore the issue and stick with GCC.
But MSC gives a dll 1/4 of the size, so I'd rather get it working if
at all possible.

Can anyone tell me how to build a plugin, using C rather than C++,
with the MS C command line compiler? It can't be this hard, surely???

Paul.

 

[samintz]

Try using a .DEF file. In the EVENT plugin I wrote I use the following
.DEF file:
EXPORTS
InitializePlugin
ShutdownPlugin
GetPluginInfo
f_EventCreate
f_EventClose
EventSignal
EventReset
EventWait


Each of those functions is defined using DLLExports.

E.g.
DLLExports BOOL WINAPI InitializePlugin( void )

-Scott



"p.f.moore" <> wrote on 07/16/2008 06:19:01 PM:

> I'm having huge trouble getting my plugin to link correctly. The code
> is C, not C++ - I can compile it as C++, but it does not use any C++
> features, and I'd rather not use C++ unless I have to.
>
> The problem lies in the C name mangling (_function@N), which I cannot
> seem to get to work sanely. Part of the problem is that the SDK only
> supplies a C++-compatible import library for TakeCmd.dll. However, I
> can generate an appropriate (maybe!) .lib based on MS KB entry 131313.
>
> I'm using MS C++ 2008 Express Edition. My sources are compiled using
> cl /c lua.c. For my link, I am doing
>
> link /out:lua.dll /DLL *.obj TakeCmd.lib
>
> DLL has an export table that looks like this:
>
> ordinal hint RVA name
>
> 1 0 00001020 _GetPluginInfo@0
> 2 1 00001090 _InitializePlugin@0
> 3 2 000010B0 _ShutdownPlugin@4
> 4 3 00001550 __lua_release@4
> 5 4 00001520 __lua_version@4
> 6 5 00001260 _f_lua@4
> 7 6 00001580 _lua@4
>
> When I try to load the plugin, I get
>

> Quote:
>
> >plugin /L Lua
>
> TCC: (Sys) The specified procedure could not be found.
> "Lua"
>
> OK, what procedure???!? If I use a .def file to get names without the
> initial underscore or terminating @N, it makes no difference. If I use
> gcc, I get a .dll with *both* names in the export table, and the
> plugin loads OK. I'm baffled as to why.
>
> I've tried all sorts of combinations and variations, with different
> results which, quite frankly, I cannot explain.
>
> To a large extent, I'm tempted to ignore the issue and stick with GCC.
> But MSC gives a dll 1/4 of the size, so I'd rather get it working if
> at all possible.
>
> Can anyone tell me how to build a plugin, using C rather than C++,
> with the MS C command line compiler? It can't be this hard, surely???
>
> Paul.
>

 

[Steve Fabian]

p.f.moore wrote:
| I'm having huge trouble getting my plugin to link correctly. The code
| is C, not C++ - I can compile it as C++, but it does not use any C++
| features, and I'd rather not use C++ unless I have to.
|
| The problem lies in the C name mangling (_function@N), which I cannot
| seem to get to work sanely. Part of the problem is that the SDK only
| supplies a C++-compatible import library for TakeCmd.dll. However, I
| can generate an appropriate (maybe!) .lib based on MS KB entry 131313.
|
| I'm using MS C++ 2008 Express Edition. My sources are compiled using
| cl /c lua.c. For my link, I am doing
|
| link /out:lua.dll /DLL *.obj TakeCmd.lib
|
| DLL has an export table that looks like this:
|
| ordinal hint RVA name
|
| 1 0 00001020 _GetPluginInfo@0
| 2 1 00001090 _InitializePlugin@0
| 3 2 000010B0 _ShutdownPlugin@4
| 4 3 00001550 __lua_release@4
| 5 4 00001520 __lua_version@4
| 6 5 00001260 _f_lua@4
| 7 6 00001580 _lua@4
|
| When I try to load the plugin, I get
|
|
|
| ---Quote---
|| plugin /L Lua
| ---End Quote---
| TCC: (Sys) The specified procedure could not be found.
| "Lua"
|
| OK, what procedure???!? If I use a .def file to get names without the
| initial underscore or terminating @N, it makes no difference. If I use
| gcc, I get a .dll with *both* names in the export table, and the
| plugin loads OK. I'm baffled as to why.
|
| I've tried all sorts of combinations and variations, with different
| results which, quite frankly, I cannot explain.
|
| To a large extent, I'm tempted to ignore the issue and stick with GCC.
| But MSC gives a dll 1/4 of the size, so I'd rather get it working if
| at all possible.
|
| Can anyone tell me how to build a plugin, using C rather than C++,
| with the MS C command line compiler? It can't be this hard, surely???

Sorry, I don't use it. However, I'd suggest you try a freeware compiler:
Open Watcom (from openwatcom.org), which has both command-line and #pragma
options to control name decorations.
--
Steve

 

[thomasl]

"p.f.moore" <> wrote:

> To a large extent, I'm tempted to ignore the issue and stick with GCC.
> But MSC gives a dll 1/4 of the size, so I'd rather get it working if
> at all possible.
>
> Can anyone tell me how to build a plugin, using C rather than C++,
> with the MS C command line compiler? It can't be this hard, surely???

I was having lots of trouble with the MSC stuff as well. In the end the
easiest route was to do two things: use the C++ compiler (I use almost
no C++ features, but what the heck) and create a .def file for my
plugin. These days I normally get by w/o the latter (I think the last
time I wrote a .def file must have been around 2000), but the funny way
the mangling and decoration between all libraries works (or doesn't
work;-) forced me to use one.

If you insist on pure C (why would you?) I think it'll going to be
somewhere between difficult and impossible.

--
cheers thomasl

web: http://thomaslauer.com/start

 

[p.f.moore]

On 17/07/2008, Steve Fábián <> wrote:

> Sorry, I don't use it. However, I'd suggest you try a freeware compiler:
> Open Watcom (from openwatcom.org), which has both command-line and
> #pragma options to control name decorations.

I'll have a look. Thanks for the suggestion - I always like seeing how
other compilers work.

It's not critical in this case, as I have a working(ish) build using
mingw gcc. To be honest, after last night's frustration, I've
completely lost sight of why I was trying to get MSVC working!

Paul.

 

[p.f.moore]

On 17/07/2008, samintz <> wrote:

> Try using a .DEF file.

I think at least some of my attempts involved using a .DEF file. It
may have been that the errors I was getting were unrelated (I had
errors caused by PATH issues and relevant DLLs not being on PATH,
which just made the whole thing worse...)

The error messages when a plugin fails to load are nigh-on useless.
Does anyone have a suggestion for a debugging setup for issues with
plugin loading?

Also, I infer from your suggestion that the key is having exported
functions with names

InitializePlugin
ShutdownPlugin
GetPluginInfo

Is that right? TCC loads the DLL and gets the functions by name? (As
opposed to something more obscure, like by ordinal). If that's
definitely true, then at least one of my failures was caused by
something else, as I've certainly managed to build DLLs with those
exported names. (Hmm, does TCC check that the function names promised
in GetPluginInfo are actually present at load time? I got at least one
message "Unable to find function "Lua"" which is odd, as the function
name in my code is "lua" (lowercase) and the only place I use the
capitalised version is in the PLUGIN command - "plugin /L Lua")

Thanks for the suggestion,
Paul.

 

[p.f.moore]

On 17/07/2008, thomasl <> wrote:

> If you insist on pure C (why would you?) I think it'll going to be
> somewhere between difficult and impossible.

Mainly because I'm paranoid about extra C++ RTL startup costs, that
wouldn't be needed with C. Also because getting extern "C"
incantations right seems fiddly. And finally, because I want to keep
it buildable with mingw, and I've got something working (albeit
fiddly) using C for that.

I've written very little C in years, and even less C++. Keep it
simple, basically.

Paul.

 

[Steve Fabian]

p.f.moore wrote:
| On 17/07/2008, thomasl <> wrote:
|
|
| ---Quote---
|| If you insist on pure C (why would you?) I think it'll going to be
|| somewhere between difficult and impossible.
| ---End Quote---
| Mainly because I'm paranoid about extra C++ RTL startup costs, that
| wouldn't be needed with C. Also because getting extern "C"
| incantations right seems fiddly. And finally, because I want to keep
| it buildable with mingw, and I've got something working (albeit
| fiddly) using C for that.
|
| I've written very little C in years, and even less C++. Keep it
| simple, basically.


You don't need to worry about the extra C++ RTL startup costs, since they
are already loaded to support TCC itself. In all other aspects I agree. BTW,
I never wrote C++ - the language itself grossly violates KISS.
--
Steve