Brian Dessent wrote: > Please don't hijack threads; start a new thread. Thanks for correcting me. > The mangling is there for a reason. If you exported a function with > C++ > linkage but without its name mangled then it's very likely that you > could call it from a compiler with a different C++ ABI, such as MSVC, > and that would fail. Mangling prevents this, because it requires that > to call the function you have a compiler with compatible ABI. The functions are going to be exported from a Dll, which is going to be done using MinGW. Is that still requires that client of that Dll be compiled with MinGW? > If your complaint is simply that you don't want to put mangled names in > the .def file, then I must ask: why use a .def file at all? It's > usually not needed. The GNU linker has auto-export enabled by default > which causes all symbols to be exported if __declspec(dllexport) is not > used anywhere. And if __declspec(dllexport) is used, then the source > itself already controls what functions to be exported so the .def file > is extraneous. gcc -x c++ source.cpp -o source.o gcc -shared -o source.dll my_source.o source.o I'm exporting just two functions from "my_source.o" (which I have access to, and they have __declspec(dllexport) and extern "C"). There are many other global functions in "my_source.o" which is used from "source.o", but not need to be exported from the resulting Dll. I needed .def file to export all global functions from "source.o" to not use -export-all feature (because it will export all globals from both modules regardless of __declspecs.) And I'm getting this .def file by using dlltool (MinGW component.) The problem is I need to MinGW compile a Dll as C++ not as C, and call exported functions from MSVC compiled application. Thanks, Seyran
