Compatibilidad binaria CrossCompiler en C

Question

Necesito verificar algo por lo que tengo dudas. Si se escribe una biblioteca compartida (.dll) en C, con el estándar C99 y compilada bajo un compilador. Di Mingw. Luego, en mi experiencia, es compatible binario y, por lo tanto, se puede usar de cualquier otro compilador. Diga MS Visual Studio. Digo en mi experiencia porque lo he probado con éxito más de una vez. Pero necesito verificar si esta es una regla.

Y además me gustaría preguntar si es así, ¿por qué las bibliotecas escritas por completo en C, como OpenCV, por ejemplo, no proporcionan binarios compilados para cada sistema operativo diferente? Sé que la razón obvia sería establecer todos los parámetros de tiempo de compilación, pero aparte de eso, no hay nada, ¿verdad?

Editar: estoy agregando una pregunta adicional que veo como una extensión lógica al original. ¿No es así como uno iría y crearía una biblioteca de código cerrado? Dado que la opción de dar una fuente sale por la ventana allí, dar binarios es la única opción. Y en ese caso, proporcionar binarios para la mayor cantidad de arquitecturas posible es el resultado deseado, siendo C una opción obvia para tener la mejor portabilidad entre sistemas y compiladores. ¿Derecha?

Answer 1

En el caso específico de los compiladores C (MSVC y GCC/MINGW) en el mundo de Windows, tiene razón en el supuesto de compatibilidad binaria. Se puede vincular una interfaz C DLL compilada por GCC a un programa en Visual Studio. Esta es la forma en que los proyectos C99 como FFMPEG permiten a los desarrolladores escribir aplicaciones con Visual Studio. Uno solo necesita crear la biblioteca de importación con lib.exe que se encuentra en la cadena de herramientas de Microsoft desde la DLL. O viceversa, utilizando Pexports de Mingw.org o mejor, la herramienta GENDEF de MingW-W64, se puede crear una LIB de importación GCC para una DLL producida por MSVC.

Esta práctica interoperabilidad se descompone cuando ingresa al mundo de la interfaz C ++, donde el ABI de MSVC y GCC es diferente e incompatible. Puede funcionar, puede que no, no se hacen garantías y no se realiza (actualmente) que se haga para cambiar eso. Además, la información de depuración es obviamente diferente, hasta que alguien escriba un generador de información de depuración/escritor en GCC que sea compatible con el depurador de MSVC (junto con el soporte de GDB, por supuesto).

No creo que C99 cambie específicamente nada a las declaraciones de funcionamiento o la forma en que se manejan los argumentos en las definiciones de símbolos, por lo que tampoco debería haber ningún problema.

Tenga en cuenta que, como dijo Vijay, todavía existe la diferencia de arquitectura, por lo que una biblioteca X86 no se puede usar al vincular a una biblioteca AMD64.

---

Para responder también a su pregunta adicional sobre binarios de código cerrado y distribuir una versión para todos los compiladores/arquitecturas disponibles.

Esta es exactamente la forma en que crearía un binario de código cerrado. Además de la biblioteca de importación, también es muy importante ocultar las exportaciones de la DLL, lo que hace que la DLL sea inútil para vincular (si no desea que el código del cliente use funciones privadas en la biblioteca, consulte, por ejemplo, la salida de dumpbin /exports En una DLL MSOffice, muchas cosas ocultas allí). Puedes lograr lo mismo con GCC (creo, nunca lo usé o lo probé) usando cosas como __attribute(hidden) etc...

Algunos puntos específicos del compilador:

1. MSVC viene con cuatro (bueno, en realidad solo tres restantes en versiones más nuevas) diferentes bibliotecas de tiempo de ejecución a través de /mt, /md y /ld. Además de esto, tendría que proporcionar una compilación para cada versión de Visual Studio (incluidos los paquetes de servicio) para asegurar la compatibilidad. Pero eso es binario de código cerrado y ventanas para ti ...

2. GCC no tiene este problema; MingW siempre se vincula a msvcrt.dll proporcionado por Windows (desde Windows 98), equivalente con /md (y tal vez también una biblioteca de depuración equivalente con /mdd). Pero hay dos versiones de Mingw (Mingw.org y MingW-W64) que no garantizan la compatibilidad binaria. Este último es más completo, ya que proporciona opciones de 64 bits, así como de 32 bits, y proporciona un conjunto de encabezado/biblioteca más completo (incluida una parte sustancial de DirectX y DDK).

Answer 2

La regla general es que si su combinación de OS/CPU tiene un ABI estándar, y si ese ABI es lo suficientemente poderoso para su idioma, la mayoría de los compiladores seguirán que ABI y como resultado serán compatibles con binario, lo que le permitirá vincular las bibliotecas (compartidas o compartidas o estático) compilado con diferentes compiladores a programas compilados con otros compiladores bien.

El problema es que la mayoría de los ABI son bastante débiles: están diseñados alrededor de idiomas de bajo nivel como C y Fortran y se remontan a los días previos a los idiomas orientados a objetos como C ++. Por lo tanto, tienden a carecer de soporte para cosas como la sobrecarga de funciones, operadores definidos por el usuario, excepciones, contructores y destructores globales, funciones virtuales, herencia y tal que C ++ necesitan.

Esta falta fue reconocida cuando se diseñó C ++, por lo que C ++ tiene extern "C" - que hace que el compilador se limite al ABI estándar para ciertas funciones, al tiempo que deshabilita todas las características adicionales de C ++ que el ABI generalmente no admite.

Answer 3

Una biblioteca compartida o DLL compilada a una arquitectura en particular puede vincularse a aplicaciones compiladas por otros compiladores que se dirigen a la misma arquitectura. (Por arquitectura, me refiero a una combinación de procesador/sistema operativo). Pero no es práctico que un desarrollador de la biblioteca compile contra todas las arquitecturas posibles. Además, cuando una biblioteca se distribuye en forma de origen, los usuarios pueden crear binarios optimizados para sus requisitos específicos.