Replacing DMD's kernel32.lib to include missing functions - windows

I'm using dmd 2.054 and optlink 8.00.12 on Windows 7.
The following program:
pragma(lib, "kernel32.lib");
extern(Windows) {
uint LocaleNameToLCID(const(wchar)*, int);
}
void main() {
auto us = LocaleNameToLCID("en-US", 0);
}
Gives an error when compiling:
Error 42: Symbol Undefined _LocaleNameToLCID#8
But if I try to replace kernel32.lib, I get many errors:
implib /system kernel32.lib \Windows\system32\kernel32.dll
Error 42: Symbol Undefined _LocaleNameToLCID#8
c:\dmd\windows\bin\..\lib\phobos.lib(dmain2)
Error 42: Symbol Undefined _LocalFree#4
c:\dmd\windows\bin\..\lib\phobos.lib(dmain2)
(... snip ...)
Looking at the original lib and the implib created for LocalFree shows there are differences, but I'm not sure what that means (some special characters are missing from this output)
---------- IMPLIB
LocalFree
_LocalFreekernel32.dll LocalFree
_K32GetPerformanceInfo!_LocalFree!Z
_MoveFileExA!É_QueryPerformanceCounter!c_ReadConsoleOutputA!Ó
_LocalFreeZ
---------- DMD'S
LocalFree
_LocalFree#4KERNEL32.dll LocalFree
_LocalFree#4}
Any idea how I can use the new kernel32.lib in my programs to avoid missing symbols?

Nevermind..
I had also tried using coffimplib earlier without success, but now it works. No idea what I've done earlier.
So my solution has been to download the windows sdk and using coffimplib on the libraries I need.
Sorry for the spam. If someone could tell me why implib doesn't work I'll accept that answer.

Related

nim: Use a static library

I've tried to get an audio library statically linked to my program. I use this nimble package. To get it run, i had to build the soloud library as described here. For short after download i ran "genie --with-miniaudio-only --platform=x64 vs2017" in the "build" folder and got the source code to generate the dynamic and the static library. For now i can run the following demo program from the nimble package with the generated dll alongside:
import solouddotnim, times, os
var i, spin = 0
var sl : ptr Soloud
sl = Soloud_create()
discard Soloud_init(sl)
Soloud_setGlobalVolume(sl, 1)
var stream = WavStream_create()
discard WavStream_load(cast[ptr Wav](stream), "test.ogg")
let currentTime = epochTime()
let length = WavStream_getLength(stream)
discard Soloud_play(cast[ptr Soloud](sl), cast[ptr Wav](stream))
while epochTime() - currentTime <= length:
sleep(100)
Soloud_deinit(sl)
Soloud_destroy(sl)
Now to the static-link part. In the solouddotnim.nim file of the nimble package i use, i see this part:
when defined(windows):
const
libname* = "libsoloud.dll"
elif ...
So i simple changed the windows part to the following, re-installed the nimble-package and placed the "soloud_static_x64.lib" alongside to the "main.nim" of the testproject:
when defined(windows):
const
libname* = "soloud_static_x64.lib"
elif ...
But this doesent make it. (cant open "soloud_static_x64.lib" error when build)
Evereywhere where the constant "libname" is used there are the pragmas "cdecl", "importc" and "dynlib". For example:
proc Soloud_create*(): ptr Soloud {.cdecl, importc: "Soloud_create", dynlib: libname.}
So "dynlib" is telling nim to use a dll on windows. But was is the pragma for static libraries?
In the nim documentations i only found DynlibOverride to link to static libraries, but i dont understand the example and here is where i stuck. I've tried the followings:
nim c --dynlibOverride:libname --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
nim c --dynlibOverride:soloudtotnim --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
Firstly i dont know what parameter dynlibOverride expects and secondly both compiles, but dont work. It expects a dynamic library alongside the exe.
My last try was to remove all dynlib pragmas from the nimble package. But now i cant compile it.
undefined reference to `Soloud_create'
...
Error: execution of an external program failed: 'gcc.exe...
My knowlege ends here. Can someone help me?
Thanks in advance.
Edit:
I could not get any of your solutions work. I break down the problem as small as possible so everybody can reproduce this:
"foo.nim" contains this:
proc add*(a, b: int): int {.cdecl, exportc.} =
a + b
proc sub*(a, b: int): int {.cdecl, exportc.} =
a - b
The .lib is simply generated with this command: "nim c --app:staticlib foo.nim"
Now to use it i created a file "main.nim" with this content:
{.passL:"foo.lib".}
proc add*(a, b: int):int {.cdecl, importc.}
proc sub*(a, b: int):int {.cdecl, importc.}
echo add(10, 5)
echo sub(10, 5)
if i simply build it with "nim c -r main.nim", i get the following output and error:
P:\Nim\LearnCBinding>nim c -r main.nim
Hint: used config file 'C:\nim-1.5.1\config\nim.cfg' [Conf]
Hint: used config file 'C:\nim-1.5.1\config\config.nims' [Conf]
....CC: stdlib_io.nim
CC: stdlib_system.nim
CC: main.nim
Hint: [Link]
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x1f6): multiple definition of `PreMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x120): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x20a): multiple definition of `PreMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x134): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x240): multiple definition of `NimMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x16f): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x254): multiple definition of `NimMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x183): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x285): multiple definition of `main'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x1b4): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x2da): multiple definition of `NimMainModule'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x209): first defined here
collect2.exe: error: ld returned 1 exit status
Error: execution of an external program failed: 'C:\nim-1.5.1\dist\mingw64\bin\gcc.exe -o P:\Nim\LearnCBinding\main.exe C:\Users\Peter\nimcache\main_d\stdlib_io.nim.c.o C:\Users\Peter\nimcache\main_d\stdlib_system.nim.c.o C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o foo.lib '
Because of the multiple definition error i also tried to build foo.lib with parameter "--noMain:on", but it doesnt make any difference.
Do you have the same problem? By the way i use the current version of Nim "nim-1.5.1" and reinstalled MingW with the finish.exe from nim.
I will try to help you with the following error you have:
undefined reference to `Soloud_create'
but i will assume that you have configured your environment so you can compile your nim programs with visual studio compiler (by adding --cc:vcc to your compile command)
this is because you already seem to have visual studio 2017 and you are compiling soloud static library with it. I think this is the best option when you are compiling with one compiler both: static library and executable that will use it.
open your static library (soloud_static_x64.lib) with some text/hex editor and search for "Soloud_create". i guess you will not find anything. so why is that? because for some reason author decided to not include "C interfacing" in a static library project. so it contains only C++ symbols and not pure C symbols that are needed for our solouddotnim.nim module.
let's try to find out what .cpp file we need for that. i noticed this information on official web site of Soloud - http://sol.gfxile.net/soloud/c_api.html
so i guess we need only one file: soloud_c.cpp
let's try to just include it in SoloudStatic.vcxproj file generated by you with Genie. like this:
..
<ClCompile Include="..\..\src\c_api\soloud_c.cpp">
</ClCompile>
..
and recompile our static library. i use this command in powershell:
& 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\MSBuild.exe' /p:PlatformToolset=v142`;WindowsTargetPlatformVersion=10`;Configuration=Release`;Platform=x64 .\SoloudStatic.vcxproj
but you can compile how you want. just make sure that it's architecture is really x64. you can check it with this command:
dumpbin /headers soloud_static_x64.lib | more
finally just link it with your nim file. add this line to the top:
{.link:"soloud_static_x64.lib".}
and compile nim file with this command:
nim c --cc:vcc --dynlibOverride:libsoloud.dll -r "examples\00-ogg\Example00_ogg.nim"

Importing functions from C static library in D?

I have already converted static lib to OMF format, but still have message like:
.dub\build\application-debug-windows-x86-dmd_2066-1C1E0ED068478598700706764846CD8E\ftdi.obj(ftdi)
Error 42: Symbol Undefined _FT_Open
In program I have import functions with method which I have already used. And it was worked for me with another libs.
pragma (lib, "ftd2xx_OMF.lib");
extern (C)
{
FT_STATUS FT_Open(FT_HANDLE, ulong*);
FT_STATUS FT_Close(FT_HANDLE);
//...
};
Library exists and really includes these functions. I've checked it through generating export/import lists by coffimplib.exe.
Any ideas?

compile option for rcpp and lib files in windows

Hi I am trying to work with the rcpp. For this I want some cpp code which loads a dll by use of a lib-file (which has the same name as ). the code which I let run is:
cppFunction(includes=c("#include "windef.h","#include \"C:/data/Rdata/IHUAPI.H\" "), 'int functietom(int a){long serverhandle;int lRet;lRet = ihuConnect ( "historian1",NULL,NULL, &serverhandle ); return 5;}', verbose
= TRUE)
I get the following error:
undefined reference to `ihuConnect#16' collect2: ld returned 1 exit
status Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object
'C:/Users/user1663/AppData/Local/Temp/RtmpSW1Ki7/sourcecpp_1a04df63309/sourceCpp_26588.dll':
LoadLibrary failure:
the ihuConnect function is located in the ihuapi.lib and ihuape.dll files. In c++ in visual studio I add the lib file as added dependency and then I get rid of this error because I also sometimes get this error and then it was that I forgot to add the lib file in the compilation.
Thus My question is: how can I add this lib file as option in the compilation.
when I use dyn.load
("C:/data/Rdata/ihUAPI.dll")
and then check if it is loaded then he says yes
the problem is that getDLLRegisteredRoutines('ihUAPI', addNames = TRUE)
then it says:
data frame with 0 columns and 0 rows
so the dll seems not to contain the functions but it does when I use it from visual studio.
So please some help with lib-files and ddl-files
Tom Wambecq
You missed the Rcpp FAQ entry 2.9 'Can I use Rcpp with Visual Studio ?'.
And to kill all the suspense: No, you cannot.

Link Error 2001 when linking to User32.dll

I'm trying to link an object file that uses two methods declared in winuser.h and defined in User32.dll: GetMonitorInfo and WindowFromMonitor. The source compiles to an object file just fine, but when I try to link, I get the following error output:
D3dCtx.obj : error LNK2001: unresolved external symbol xGetMonitorInfo
D3dCtx.obj : error LNK2001: unresolved external symbol xMonitorFromWindow
The thing is, I don't call "xGetMonitorInfo" or "xMonitorFromWindow". Running grep on all source files shows that only "GetMonitorInfo" and "WindowFromMonitor" are being called. I'm properly including windows.h, which includes winuser.h. I'm also properly setting my LIBPATH in the linker options, which is confirmed by verbose link output.
The following also appears in my verbose link output:
Found __imp_GetMonitorInfoA
Referenced in nafxcw.lib(afxribboncategory.obj)
Referenced in nafxcw.lib(afxtooltipctrl.obj)
Referenced in nafxcw.lib(afxribbonkeytip.obj)
Referenced in nafxcw.lib(afxfullscreenimpl.obj)
Referenced in nafxcw.lib(afxframeimpl.obj)
Referenced in nafxcw.lib(afxglobalutils.obj)
Referenced in nafxcw.lib(afxdropdowntoolbar.obj)
Referenced in nafxcw.lib(wincore.obj)
Referenced in nafxcw.lib(afxglobals.obj)
Referenced in nafxcw.lib(afxpopupmenu.obj)
Referenced in nafxcw.lib(afxpropertygridtooltipctrl.obj)
Loaded User32.lib(USER32.dll)
Found __imp_MonitorFromWindow
Referenced in nafxcw.lib(wincore.obj)
Loaded User32.lib(USER32.dll)
Furthermore, GetMonitorInfo is defined in winuser.h as:
WINUSERAPI
BOOL
WINAPI
GetMonitorInfoA(
__in HMONITOR hMonitor,
__inout LPMONITORINFO lpmi);
WINUSERAPI
BOOL
WINAPI
GetMonitorInfoW(
__in HMONITOR hMonitor,
__inout LPMONITORINFO lpmi);
#ifdef UNICODE
#define GetMonitorInfo GetMonitorInfoW
#else
#define GetMonitorInfo GetMonitorInfoA
#endif // !UNICODE
When I change all reference to "GetMonitorInfo" to "GetMonitorInfoA", I only get
D3dCtx.obj : error LNK2001: unresolved external symbol xMonitorFromWindow
as my linker error output. Unfortunately, MonitorFromWindow doesn't seem to have multiple versions available.
I should note that I am using the 64bit versions of the libraries, link, and cl.
What's going on here, and how can I successfully link my program?
I don't know whether you were able to find solution to this or not But I had the same problem and the reason this was happening was that I had a file included named multimon.h
Looks like in case of 64 bit compilation, due to Macro definitions, the definitions of these functions are coming from two sources and probably one from multimon.h is overriding and is wrong.
I solved it by just commenting out this include and it has started to link fine.
//#include <multimon.h>

Xcode linker and blocks: Undefined symbol "___block_global_1"

I am trying to build an application in Xcode 3.2.4 and am getting the following linker error:
Undefined symbols:
"___block_global_1", referenced from:
___block_holder_tmp_1.120 in foobarbaz.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I'm at a loss to explain what I've done in my source file that might be causing the error. I do have a block that I am defining as a global variable, like so:
typedef void(^error_block_t)(NSError* error);
error_block_t error_handler_s = ^void(NSError* error)
{
//...
}
This block is defined in an empty namespace in the source (I'm compiling Objective-C++.) Everything compiles without error.
Update: Moving the block to be a local variable for the routine that references it is a viable (though not preferred) workaround.
What gives?
If the error_handler_s is not intended to be exported, you could make it static as another workaround.
namespace {
...
static error_block_t error_handler_s = ^void(NSError* error) { ... };
...
}
Otherwise, I believe this is a bug in gcc.
At this point I believe this issue to be a bug.

Resources