After doing a little more research into .def files, it appears we could use one to export all of the functions. However, according to the MSDN documentation...
"Note that when you export a variable from a DLL with a .def file, you do not need to specify __declspec(dllexport) on the variable. However, in any file that uses the DLL, you must still use __declspec(dllimport) on the declaration of data." So in other words, we may only need to add the XMLIBEXPORT to the variables like xmArrowButtonWidgetClass. And we'd still have to create a file listing all the functions to export. Still a pain, but maybe less pain than adding an XMLIBEXPORT line to every function and vairable that needs to be exported.. ----- Original Message ----- From: "Dave Williss" <[EMAIL PROTECTED]> To: "Danny Backx" <[EMAIL PROTECTED]> Sent: Tuesday, June 01, 2004 9:25 AM Subject: Re: [Lesstif] Exporting functions from DLLs in Windows > The XMLIBEXPORT gets defined to be either __declspec(dllimport) > or __declspec(dllexport) (or just exern if not compiling on Windows) > > When building the library, dllexport tells the compiler/linker > to actually make the symbol visible outside the dll. Without it, its as > if the entire dll is one module and all the functions are static. > You can accomplish almost the same thing as dllexport by creating a > .def file which lists all the functions to export and passing that to the > linker. This, however has other limitations that I'll explain later. > > When an include file is used by code that will eventually link to the dll > and pull functions from it, the dllimport tells the compiler that the > function > will be coming from a dll, which causes it to behave slightly differently. > I believe in the past it had to generate a small wrapper function that > would lookup the function in the dll and call it indirectly. I don't think > they actually do this any more unless you mark the DLL as delay loaded, > in which case the wrapper loads the DLL if it hasn't already done so. > > The reason that the .def file is useless (unless I'm missing something) is > that when you export symbols from a dll, they get __imp__ prepended > to the names, and the linker knows what to do with this. If you don't have > __declspec(dllimport) in front of the prototypes when compiling code > that links to the dll, it won't know that and will look for functions > without > the __imp__. So you still have to put something in front of every prototype > that's to come out of a dll. > > > > > ----- Original Message ----- > From: "Danny Backx" <[EMAIL PROTECTED]> > To: "Dave Williss" <[EMAIL PROTECTED]> > Cc: "LessTif Mailing List" <[EMAIL PROTECTED]> > Sent: Monday, May 31, 2004 4:19 AM > Subject: Re: [Lesstif] Exporting functions from DLLs in Windows > > > > I believe Alexander has been doing similar things for OS/2. > > I'll have a peek. > > > > I'm not too familiar with NT. I guess exporting symbols in > > this way makes a difference. Could you tell me exactly what > > it causes ? > > > > Danny > > > > On Fri, 2004-05-28 at 19:57, Dave Williss wrote: > > > I'm building lesstif as a dll on Windows and ran across a problem > > > which is tedious to fix but not very difficult. The include files > > > don't > > > export anything. > > > > > > To fix this, I added the following lines to Xm/Xm.h > > > > > > #ifdef WIN32 > > > #ifdef XMDLL /* <-- Set this when compiling Lesstif as a > > > DLL */ > > > #define XMLIBEXPORT __declspec(dllexport) > > > #else > > > #define XMLIBEXPORT __declspec(dllimport) > > > #endif > > > #else > > > #define XMLIBEXPORT extern > > > #endif > > > > > > I then went through all the include files and added XMLIBEXPORT > > > in front of every function that needs to be exported (and maybe some > > > that don't) > > > > > > Now I have a set of Xm include files which export functions from the > > > DLL, and when my applications include them, they know that the > > > functions > > > are to be imported from a DLL. This is unnecessary for gcc on Unix > > > machines, but necessary for Microsoft VC compiler on Windows. > > > > > > The logic on when XMLIBEXPORT is set to what may need to change. > > > It doesn't account for the possibility of static linking on Windows, > > > for > > > example. > > > > > > Once I had changed all the include files (unfortunately in a merged Xm > > > directory, not separated out by version like in the distribution) I > > > used > > > Araxis Merge to generate a diff report for the whole thing. This gave > > > a diff file for each changed file. > > > > > > I posted the report on our web site here... > > > > > > http://www.microimages.com/LesstifIncludeFileChanges/ > > > > > > This is temporary. I'll take it down in a couple weeks. > > > > > > Comments about exporting symbols from the DLL are welcome. > > > If anybody has a better idea, let me know. If you'd like a better > > > form of diff, tell me know the command line parameters to standard > > > Unix diff to generate the output you'd like. > > > > > > > > > -- Dave Williss > > > ------ > > > Meddle not in the affairs of dragons, > > > for you are crunchy and taste good with catsup > > -- > > Danny Backx - danny.backx-at-skynet.be > > > > _______________________________________________ > > Lesstif mailing list > > [EMAIL PROTECTED] > > https://terror.hungry.com/mailman/listinfo/lesstif > _______________________________________________ Lesstif mailing list [EMAIL PROTECTED] https://terror.hungry.com/mailman/listinfo/lesstif
