Hi everybody,
this is my first post here — nice to be onboard!
I've been experimenting with Nim and I really enjoy it.
I'm working under Win 10 x64. I don't use MinGw compiler suggerst by Nim installer, I instead use TDM-GCC, which is working very well.
I've tried to create libraries with Nim to use with another language: PureBASIC. So I started with the Fibonacci example from the documentation.
With the DLL everything went fine: compiled, imported the DLL in my PureBASIC code and I've accesed the fib() function from the DLL easily.
With the static library I'm experiencing some difficoulties and I really don't know what else to try. I am no C expert, nor I know deeply GCC, but so far I've managed to compiler quite a few C projects without problems.
PureBASIC can include C libraries with either stdcall (the default) as well as not stdcall -- it auto-decorates them, the former as _FunctionName@callsize, the latter as _FunctionName. But on x64, it has only one calling convention (stdcall, I seem to understand).
It can import function from a library (.lib) or an object (.obj) file.
When I try to import the static lib functions I get an error from Pelles C polink (used by PureBASIC compiler):
POLINK: Unresolved external symbol 'fdopen'
POLINK: Unresolved external symbol 'fileno'
POLINK: Unresolved external symbol ''__strtod'
I am compiling the Fibonacci Nim example with:
nim c --app:staticLib --noMain --header fib.nim
And I get a "fib.lib" file -- which I gather should be the static lib, not needing any dependencies.
I've tried changin in the Nim source the "exportc" pragma:
proc fib(a: cint): cint {.cdecl, exportc.} =
if a <= 2:
result = 1
else:
result = fib(a - 1) + fib(a - 2)
and:
proc fib(a: cint): cint {.stdcall, exportc.} =
But both failed...
What am I missin out/doing wrong?
Any hints to unlock the situation and set me in the right direction would really help!
Thanks,
Tristano (Italy).
UPDATE: I've tried compiling as "release" and polink errors reduced to one unresolved ext.symbol:
nim c -d:release --app:staticLib --noMain --header fib.nim
POLINK: Unresolved external symbol 'fileno'
maybe some of the symbols where Debugger related?
Hi @Krux02,
No, I didnt. PureBASIC only uses "polink" and "porc" and "polib" from the Pelles C -- and they seem to be from different version releases also. PureBASIC has its own compiler + a FASM compiler. Unfortunately the documentation doesn't provide much help (actually: none) when it comes to these deatails. But it says it should handle any C library alright -- but then, again, PureBASIC is cross-platform but has a single documentation, so it might be referring actually to Linux or Mac.
But I'll try to look into Pelles C documentation, hoping it might help.
Would you have any idea what this 'fileno' unresolved symbol might refer to? The other two went away when I disable debugger support in the final lib, so maybe this symbol could also be resolved by either including and extra (required) lib, or by an extra compiler option of sorts...
B.R.
SOLVEEED!
I've solved it by telling PureBASIC compiler to pass this option to polink:
/EXPORT:fileno
I haven't yet understood what was going on. But I do understand that his option exports the "fileno" symbol, which was the only one left in the error reports.
Can anyone help understand why this symbol was missing, what it refers to?
Shouldn't Nim have taken care of it? Or does Nim give for granted that some C code importing the header files will handle it?
It seems such a small issue, yet it kept me turning in circles for quite a long time...
Pelles C is not supported by Nim and it seems to lack fileno which Nim's stdlib depends on, might be called _fileno in Pelles C. I'm not sure what /EXPORT:fileno does so if you get random crashes, don't complain. :-)
I would stick to DLLs for interop with PureBasic.
Thanks Araq. In the end I guessed it was related to stdin/out because I grepped "fileno" into GCC's header files and it came up in the context of filesystem related constants.
Mhhh ... so I might be getting away with a simple Fibonacci function, but get a crash with more complex stuff! I've read many posts of people having problems importing static libs into PureBASIC under Windows, and that using DLL is always simpler. But in this case I was trying to experiment with static libs.
I've seen on PureBASIC forums that often errors similar to the ones I got were related to a missing system DLL (like some specific version of MS Visual Studio redistributables, ecc.) and was solved by importing the required DLLs along with the static libs....
I guess that I'll eventually get a grip on this, with more practice and insight into the nebulous world of all these trans-compiler operations --- I mean: soooo many options just for GCC compiler alone! it's east to get lost in this configuration/compatibility jungle.
;-)