Bug 1306 – extern (Windows) should work like extern (C) for variables
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2007-07-02T03:21:00Z
Last change time
2014-02-16T15:22:45Z
Keywords
link-failure
Assigned to
bugzilla
Creator
torhu
Comments
Comment #0 by torhu — 2007-07-02T03:21:51Z
In some cases, extern (Windows) causes '@0' to get added to the end of symbols that represent variables. This causes linking errors. I wasn't able to create a simple test case, but the problem should be clear.
Scenario:
I have a few hundred function pointers in a C library. To link with those, I have to use extern (C). But to actually call the functions, I need the function pointers to have type extern (Windows). Since extern (Windows) changes the mangling of the pointers, I can't link both link with the C library, and call the functions successfully. So I'm stuck, and probably need some ugly workaround.
I compiled 'int __stdcall x;' with msvc 6, which it accepted with a warning. Looking at the object file, the symbol was not affected by __stdcall. So DMD's behavior is probably wrong.
Comment #1 by braddr — 2007-07-02T10:33:19Z
Please include a set of reproduction steps, including source code.
Comment #2 by torhu — 2007-07-02T11:41:02Z
I nailed, it's another problem with the export keyword.
stdcall.d:
---
export extern (Windows) void (*funcptr)(int);
void main()
{
funcptr(5);
}
---
Just to show how funcptr gets mangled:
c:\prog\test\D>dmd stdcall
c:\prog\dmd\bin\..\..\dm\bin\link.exe stdcall,,,user32+kernel32/noi;
OPTLINK (R) for Win32 Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved
c:\prog\dmd\bin\..\lib\phobos.lib(dmain2)
Error 42: Symbol Undefined _funcptr@0
--- errorlevel 1
funcptr is mangled as _funcptr@0, which I believe is a stdcall function of zero arguments. This is clearly wrong, and won't link with the corresponding C definition of the function pointer.