Dll Creada En Vsc++...valida En Otros Compiladores

[TheAzazel]

 Hola a todos,

me  voy a poner en ello pero antes queria saber si alguno de vosotros ya ha probado algo, sabe los problemas que da y las soluciones...

resulta q tengo una libreria creada con Visual Studio C 7 (tengo la .dll y la .lib) y me gustaria que fuera directamente linkable en por ejemplo, DevC++(mingw), he hecho una prueba rapida y tal...y me ha dado mas errores q lineas en la libreria.....
en fin, cualquier comentario o problema(resuelto o sin resolver) es de agradecer,

un saludo

[senior wapo]

 Si la librería es en C puro y solo exporta funciones (no variables), deberias poder linkar la DLL, tal vez tengas que generar un .lib en el formato nativo de cada compilador (a partir del .DEF y la .DLL, no hace falta recompilar).

Si la DLL es en C++, basicamente, olvidate: tendrás que recompilar y generar un DLL para cada compilador. La razón es que los nombres de funciones/variables en C++ se exportan codificados con distintos formatos según el compilador. También puede cambiar el ABI (formato en que se representan en memoria los objetos y convenio de paso de variables en registros).

Sin ir mas lejos, VC++ pasa el puntero this en el registro ECX mientras que GCC lo pasa como un valor más en la pila.

[sés]

 Las DLLs deberían ser válidas para cualquier compilador, de hecho no tienen nada que ver con el compilador, ya que se cargan en tiempo de ejecución.

Las librerías estáticas son otra historia, tendrás que hacer una para cada compilador. No creo que haya ninguna solución, solo tienes que mirar SDL o FMOD. FMOD, por ejemplo, trae una librería para cada compilador (fmod_vc.lib, libfmod.a...).

[Sacrifai]

 Yo de DLL no he visto mucho, pero recuerdo que para hacer DLL para blitz tenias usar :

extern "C"
{
     ...
}


¿Te sirve?

[TheAzazel]

 Los dos teneis razon, las dll funcionan en todos los sistemas(una dll es una dll) pero para que sea asi...cambia el modo de acceder a ella, yo quiero utilizar el .lib y .h y olvidarme de andar con getprocess y bla bla bla.... y como dice senior wapo ya me temia yo que no fuera un standard...pense q el name mangling era standard en C++ pero nanai.. y luego eso del parametro this...en fin, q mejor se recompila (manda webs!).
Y si, SDL es una unica dll pero esta en C, no C++...aunq echare un ojo a la distribucion q tienen de desarrollo para visual studio y para mingw a ver que es lo q cambia.... si fuera solo el .lib....seria hasta gracioso y todo pero me temo q no sera tan facil....
si se os ocurre algo mas o sabeis algo mas...gracias por adelantando

[TheAzazel]

Yo de DLL no he visto mucho, pero recuerdo que para hacer DLL para blitz tenias usar :

extern "C"
{
     ...
}


¿Te sirve?

Se me colo tu respuesta jeje,
usar extern "C" es una posible solucion...pero que dijo senior wapo del parametro this y cosas similares...como podria solucionarlo????

[Sacrifai]

Se me colo tu respuesta jeje,
usar extern "C" es una posible solucion...pero que dijo senior wapo del parametro this y cosas similares...como podria solucionarlo????

Pues no veo otra solucion que, o compilarlos en todos, o Open Source  (ole)  .

[TheAzazel]

 Tras pegarme gran parte del dia con esto en la cabeza y en mis ratos libres buscar y probar... el problema me lo encuentro con las clasecitas y sus decorados nombres... no hay forma de q mingw los entienda? si tengo q modificar el .def a pelo no problem... pero kiero un .lib que compile con la misma dll... asi el problema se reduce a fabricar .lib para cada compilador utilizando la misma dll...
a alguien se le ocurre algo? o debo reclamar al comite de standard de C++ por no haber estandarizado las funciones decoradas??? jajaja  :(  

[martiño]

 Los nombres decorados los puedes obtener en el VC usando la opción de crear archivo map.

[TheAzazel]

 Ya, pero eso es mejor para pillar errores de proteccion de memoria... para sacar los nombres hay varias utilidades (pexports, dependecy walker, o incluso dumpbin).
Bueno, yo dimito :), voy a poner aqui hasta donde he llegado por si alguien me dice q no existe, q es imposible o q existe una utilidad q lo hace.... (en alguna web lei que el gnuC terminara siendo compatible con los .lib del msvc...pero no lo he visto en ningun roadmap y a saber cdo hacen eso si es cierto...).

Resulta que el extern C no me vale pq uso clases..y esas y sus miembros van a ir decoradas SIEMPRE, consigo el  .def y con el, utilizando dlltool de las gnu binary tools genero una libreria de importacion de mi dll(compilada con msvc) .lib que en teoria, deberia haber funcionado... pero que va, compilo y linko algo con gcc utilizando esta .lib y todos los nombres decorados(todas las clases y sus miembros) estan missing... el gcc me dice que no encontro la referencia(y normal, pq el no entiende la decoracion de msvc) y vale, entre las funciones de msvc y gnu cambian aspectos como el paso de parametros y demas... pero ambos..... deben soportar(aunque sea forzando las stdcall). Y bueno, para no liar las cosas... a ver si me puedo explicar lo mas claro posible:

- la DLL original esta compilada con msvc tiene las clases decoradas con el "idioma" de msvc. Su .lib original igual, utiliza el "idioma" de msvc y todo funciona perfectamente.

-Creando un .lib con dlltool utilizando la DLL original y el .DEF con los nombres decorados originales se deberia poder de algun modo conseguir que gcc entendiese las clases de la DLL. Tiene que haber algun sistema de cambiar la nomenclatura de msvc por la de gnu en el fichero .def y asi, utilizar la DLL

No he encontrado nada que haga eso pero...me molesta bastante al pensar por ejemplo, las directx son dll...son clases....nombrecitos decorados a lo msvc...y sin embargo...se pueden utilizar con gnu, borland y demas... como lo hacen?? quien ha generado dichos .lib?? como lo han hecho???

cualquier luz sobre el tema.... es de agradecer.

PD: lo flipo, como nos complican la vida....