NO

Author Topic: VC, clang and others ABI compatibility  (Read 1422 times)

dkrikun

  • Guest
VC, clang and others ABI compatibility
« on: March 17, 2016, 08:43:54 PM »
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!

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1587
Re: VC, clang and others ABI compatibility
« Reply #1 on: March 18, 2016, 09:46:57 AM »
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++.
« Last Edit: March 18, 2016, 09:50:57 AM by frankie »

dkrikun

  • Guest
Re: VC, clang and others ABI compatibility
« Reply #2 on: March 19, 2016, 02:29:31 PM »
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?

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1587
Re: VC, clang and others ABI compatibility
« Reply #3 on: March 19, 2016, 05:06:47 PM »
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.
« Last Edit: March 20, 2016, 09:26:58 PM by frankie »

dkrikun

  • Guest
Re: VC, clang and others ABI compatibility
« Reply #4 on: March 20, 2016, 08:16:43 PM »
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?

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1587
Re: VC, clang and others ABI compatibility
« Reply #5 on: March 20, 2016, 08:41:31 PM »
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.

Offline SHwareGuy

  • Member
  • *
  • Posts: 1
Re: VC, clang and others ABI compatibility
« Reply #6 on: December 11, 2016, 04:00:27 PM »
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.