Hi Howard, * Howard Chu wrote on Wed, Apr 27, 2005 at 04:18:12PM CEST: > Ralf Wildenhues wrote: > > >>Since LT_SCOPE is only used for the three lt_*alloc/free function > >>pointers, I suggest removing these declarations completely and using > >>accessor functions to set/get their values. > > >Erm, does this apply to data objects only (as opposed to functions)? > >We have several functions with LT_SCOPE. With branch-2-0 and HEAD of > >libltdl things get more intricate. Their failure on mingw have to do > >with these LT_SCOPE issues. > > Correct. On Windows, function invocations always work correctly > regardless of whether you declspec(import) them or not. As such, the > only thing you must get right is your declspec(export)'s to make sure > that functions actually get exported where they're needed. But for data > items, if you don't import correctly, you wind up with multiple copies > of the data object. I found that my programs crashed immediately (in > malloc) when calling lt_dlopen on a module that also used libltdl, > because that module had the alloc pointers declared as exports and not > as imports. > > As such, the best solution is never to expose data objects directly, > just use accessor functions and then there's nothing to worry about.
In branch-2-0 and HEAD we actually don't use the lt_*alloc/free interface any more, seems for good reason. We do still define a stub interface for backward compatibility, but given these arguments, I think we can safely delete them completely, or at least hide them on win32. OTOH, we now have a couple more objects we export[1], and from your explanations I can only gather that this needs to be fixed. It might need an incompatible change on branch-2-0 (which affects the interfaces added on the branch). Related question: Do I have to specify the declspec(export) in the same translation unit in which I define the function? This is what bugs us in mingw ATM. Specifying the declspec in another translation unit seems to work with cygwin but fail on mingw. (Of course, the unit gets linked into the same lib in any case). Thanks for your helpful comments, Ralf [1] lt__error_strings, *_preloaded_symbols, maybe lt__last_error as well.
