VC, clang and others ABI compatibility

[dkrikun]

Hello,

I would like to use Pelles C, I have lots of C .lib and .dll compiled with Visual Studio (2010 till 2015 versions).

Is Pelles C ABI compatible with Visual Studio?
What about other toolsets, like Clang and MinGW?

Thanks!

[frankie]

Welcome.
Under MS OS the ABI is standardized, so any DLL compiled by any compiler targeted for MS OS will do.
Probably you want to ask about object libary format more than ABI (which is about the runtime code layout). Well here there is a little difference. PellesC use PE format (MS Portable Executable forrmat), but some compilers can use COFF or OMF. PellesC should be able to handle also OMF libraries or object files, but not COFF (PE is very close to COFF, the only difference is how offsets are intended. This is a vengeance of David N. Cutler that when in charge in MS, coming from DEC Digital corp, made all modifications that he considered right, breaking on many points the posix compatibility. Very famous his "getta byte, getta byte, getta byte byte byte" against *nix I/O model that nowadays creates a lot of p.i.a. when handling discrete I/O transfers on non posix systems. I'm happy now because a said something that I kept for long time  , for me this was a p.i.a on VMS and still is on NT and similiar...).
Back to the point if you have a DLL, but the import library is in the wrong format you can still use polib to create the correct .lib (see help).
P.S. PellesC is a C compiler not C++, meaning that you can use only C libraries, not C++.

[dkrikun]

Thank you for your answer!

I'm not sure I understand what are the implications of PE etc. formats. I will rephrase my question:

1. Given a static library built using Visual Studio (e.g. 2015) using C language, will linking to it from PelesC work ok?
2. The same with a shared library, will I be able to load, it and call functions as usual?

[frankie]

Visual studio objects and libraries, static or dynamic, will link directly because are  created in PE format.
On some gcc compiler suites you may have problems (object format can be elf), even if final executable is PE.
As a rule of thumb if generated object files have extension .obj and libraries having extension .lib, any other extension can be incompatible formats.

[dkrikun]

So I tried to link against glfw3 static library and I've got these errors:

Code: [Select]

POLINK: error: Unresolved external symbol '__security_cookie'.
POLINK: error: Unresolved external symbol '__imp___stdio_common_vsprintf'.
POLINK: error: Unresolved external symbol '__security_check_cookie'.
POLINK: error: Unresolved external symbol '__GSHandlerCheck'.
POLINK: error: Unresolved external symbol '__imp___stdio_common_vsscanf'.
I guess this somehow has to do with VS security checks.. Can this be fixed?

[frankie]

Where you got these libraries? Are they precompiled?
The missing functions referring to coockies are due to a library compilation using /GS switch. If you want to use them you have to add the MS lib bufferoverflowU.lib.
The other missing symbols are from the new stdio libs, try to use the libraries compiled under VC++2012 or VC++2013.
The best option is to build the library yourself from the sources.

[SHwareGuy]

Thank you for your answer!

I'm not sure I understand what are the implications of PE etc. formats. I will rephrase my question:

1. Given a static library built using Visual Studio (e.g. 2015) using C language, will linking to it from PelesC work ok?
2. The same with a shared library, will I be able to load, it and call functions as usual?

1. No, probably not. While theoretically you should be able to, with Pelles and VC both using COFF format, the libraries MS ships have stripped symbol tables leading to internal routine names not being locatable. The names that other modules may have references to anyways are from tables internal to the VC compiler DLL, or are part of the debug versions of the libraries. The linker definitions file usually includes only the import by index entries for the retail versions, not the import by name entries, for entry points not intended to be referenced using GetProcAddress.

2. Possibly, if you create a Pelles specific import lib for each DLL with POLIB. The symbols headers don't reference will be pre-converted to indexes if necessary so there will be few to no unresolved symbols, unless a library is looking for callbacks into a particular executable. The problem of routines exported only by index still remains however; use of the library somewhat limited to the routines that GetProcAddress can see as named values and you have prototypes in a header for the parameters.

Side note, to expand on frankie's reply: COFF is the format for object files and static libs that MS developed. The extension doesn't really matter, it's magic numbers and header bits that determine whether it's a static library or single object for the linker to use. Intel's OMF is similar, defining the library and object format, but ELF more describes the object format only, static libs are generally compatible with the ar library utility as a separate format. COFF's focus is processing a flat address space efficiently at load time; OMF get's flat handling as a subset of it's segment/offset original focus for creating DOS and DPMI/Win16 executables, extended to the 32 and 64 bit addressing types. PE format is that used by files intended to be accessed using the LoadModule and CreateProcess APIs, such as EXEs, DLLs, Drivers, and Resources Libraries and includes the extra tables the loader needs to relocate the images in the running process tables. It otherwise shares many structures with COFF, but they are different formats.