Using External .LIB does not compile with C Backend

[JoeC4281]

As discussed in the thread viewtopic.php?p=608204#p608204

The C backend does not like the decorated name from TakeCmd.lib (?Command@@YAHPEB_WH@Z)

Windows 10 [Version 10.0.19045.3448] 22H2
PureBasic 6.02 LTS (Windows - x64)

Joe

[Fred]

It looks like a C++ mangled name, or internal C naming convention which should not be used by external programs. Proper exported functions should not be decorated like this, so it's probably a bug in the TakeCmd.lib (or at least an undocumented feature).

[idle]

It looks like a C++ mangled name, or internal C naming convention which should not be used by external programs. Proper exported functions should not be decorated like this, so it's probably a bug in the TakeCmd.lib (or at least an undocumented feature).

It works with the Fasm backend. The issue seems to be because of passing the import on to the assembler. I don't know how you alias an extern in c.

[Fred]

The fact it works with FASM doesn't imply it's the right way to do it . You usually never use decorated function directly.

[idle]

The fact it works with FASM doesn't imply it's the right way to do it . You usually never use decorated function directly.

I did try to explain that it was valid c output, the issue is with AS, so its not really your fault, though it could possibly be worked around.

[Olli]

In a first step, could we nest "AS" directive in a idle C macro ? (example : a 'AS' translated to 'AS ')

[idle]

Fred's handling the imports with gcc asm directive, so it's deferred to the gnu assembler which is named AS
Not to be confused with ass, of which many will atest I'm numerous of. Pain in the .. , ... hole.
I don't know how you do an alias for an import in plain c, I guess it's just a define and then an extern with that define.
It's not exactly a show shopper they can use the dlls just not the static libs.

[juergenkulow]

Code: Select all

; call "42" Windows x64 polink.exe  Access violation
ImportC "D:\dll.lib"
  myf() As "42"
EndImport

a=myf() 
Debug a 

CompilerIf #PB_Compiler_Backend<>#PB_Backend_C
  CompilerError "C Backend only" 
CompilerEndIf 

; x64
; Unhandled exception at 0x000000013f0d3a91 in polink.exe: 0xC0000005: Access violation reading location 0x0000001200052234.
; 000000013F0D3A91  cmp         byte ptr [r12+10h],2 
; 'polink.exe': Loaded 'F:\PureBasic603Beta3\Compilers\polink.exe', Binary was Not built With Debug information.
; 'polink.exe': Loaded 'C:\Windows\System32\ntdll.dll'
; 'polink.exe': Loaded 'C:\Windows\System32\kernel32.dll'
; 'polink.exe': Loaded 'C:\Windows\System32\KernelBase.dll'
; The thread 'Win64 Thread' (0x9c8) has exited With code 0 (0x0).
; Unhandled exception at 0x000000013f0d3a91 in polink.exe: 0xC0000005: Access violation reading location 0x0000001200052234.
; RAX = 0000000000052236 RBX = 0000000000000017 RCX = 0000000000484158 RDX = 00000011FFFFFFEE 
; RSI = 0000000000051DAE RDI = 0000000000000025 R8  = 0000000000000007 R9  = 0000000000000000 
; R10 = 0000000000483250 R11 = 000000013F0F8D80 R12 = 0000001200052224 R13 = 0000000000483240 
; R14 = 00000000004821A8 R15 = 0000000000483770 RIP = 000000013F0D3A91 RSP = 000000000017FC50 
; RBP = 0000000000000000 EFL = 00010204 
; 
; 0000001200052234 = 01 
; 
; >	polink.exe!000000013f0d3a91() 	
;  	[Frames below may be incorrect and/or missing, no symbols loaded For polink.exe]	
;  	polink.exe!000000013f0d2d58() 	
;  	polink.exe!000000013f0d2a42() 	
;  	polink.exe!000000013f0ce836() 	
;  	polink.exe!000000013f0dbd76() 	
;  	kernel32.dll!0000000076d25a4d() 	
;  	ntdll.dll!0000000076e5b831() 	
; 
; integer f_myf() asm("42");
;                      ^
; 
; x86 
; Error: Linker
; error: Invalid relocation symbol ''.

[Olli]

Maybe a main suggest : https://tldp.org/HOWTO/C++-dlopen/thesolution.html.
<< [...] The destructor of the interface class should be virtual in any case. There might be very rare cases where that would not be necessary, but it is not worth the risk, because the additional overhead can generally be ignored.

If your base class needs no destructor, define an empty (and virtual) one anyway; otherwise you will have problems sooner or later; I can guarantee you that. You can read more about this problem in the comp.lang.c++ FAQ at http://www.parashift.com/c++-faq-lite/, in section 20. [...] >>

An aux suggest consists in being able to add a preprocessing converter, in order to apply the main suggest.

[idle]

Now I've gone and spilt a perfectly good glass of wine all over my keyboard. Hope it lives. I sign off for the day

[Olli]

Unplug it before drink the drops.

[idle]

Unplug it before drink the drops.

I turned it off, tipped it upside down, took the Makita Blower / vacuum to it, then dried it with blow drier, so its good.

[Olli]

It seems Makita is rather tolerant : I would have refused.

We have so two main mangling standards :

- Microsoft (usual mangled name prefix : ? )
- FSF (usual mangled name prefix : _Z )

Microsoft offers a converting function :UndecorateSymbolName()
FSF, open source, gives naturally a source :
mangling.cc (Note this is part of GCC, so the FSF prefixes seems to be already able to be converted)

Now the concrete question : how do we integrate a string converting function (depending of the external library compiler : Microsoft or FSF) in a compiling process ?

(infos about FSF mangling name standard, thanks to stackoverflow.com )

[juergenkulow]

Code: Select all

D:\>undname -f ?Command@@YAHPEB_WH@Z
Microsoft(R) Windows NT(R) Operating System
UNDNAME Version 5.00.1768.1Copyright (C) Microsoft Corp. 1981-1998

>> ?Command@@YAHPEB_WH@Z == int __cdecl Command(wchar_t const * __ptr64,int)

Wiki How_different_compilers_mangle_the_same_functions
Command on x64 msvc v.19.latest C++ online Compiler
Edit: Link C++ online Compiler