From: Martin P. <li...@ma...> - 2012-05-25 16:27:38
|
Hi Geoff, On 25/05/2012 16:08, Geoff McLane wrote: > In C++ a decorated names will give indications > of what is returned by the function, and what > parameters are passed to the function - > > And it happens in both WIN32 and WIN64... Yes, but all of the freeglut functions have C linkage, so C++ name mangling isn't relevant here. We are only concerned with decorated names vs. undecorated names for stdcall functions. > And for sure when the DEF is used to create an > undecorated 'alias', then the resultant library > will hold BOTH - _glutFunction@4 and > _glutFunction - both pointing to the same > function... It's possible to export both decorated and undecorated names from a DLL, but the def file we have in freeglut results in only the undecorated names being exported, not the decorated names. > But I think it should be OFF by default. > > And as mentioned I had no problems when I compiled > and linked the 20 or so demos using NO DEF file, > in a WIN32 build. The reason we have it is for binary compatibility with GLUT for win32. If we don't require binary compatibility with GLUT for win32, then sure we can export the names however we like, but my understanding is that freeglut is supposed to be able to be used as a drop-in replacement for GLUT for win32. If you take the freeglut DLL that you have built, create a hard link to it named "glut32.dll", and then run an application compiled against GLUT for win32 using that DLL, the application will fail to start. Additionally, without the def file you can lose binary compatibility between freeglut DLLs built with different win32 C compilers. For example MSVC will export "_glutFunction@4", whereas MinGW will export "glutFunction@4" (no leading underscore). If you install an MSVC application which deploys the DLL to a directory in the %PATH% environment variable, and then you install a MinGW application which overwrites that DLL then the MSVC application will no longer work. If the MinGW application decides not to overwrite the DLL and uses the DLL which is already there, then the MinGW application won't work. By exported undecorated names then you don't run into this problem. We should drop the def file only if we can find an elegant solution to exporting undecorated names, or if we no longer require binary compatibility with GLUT for win32, older freeglut builds, and freeglut builds built with different compilers. Regards, Martin |