Re: Win32 libltdl issue

[Howard Chu]

Ralf Wildenhues wrote:
> > This situation is quite ugly because it means the user's *code* has to 
> > know whether they are linking against a shared or static libltdl, and 
> > it's just not possible to determine this dynamically/automatically at 
> > compile time.

> Hehe.  Note that I have only very limited knowledge about linking under
> Win32, but this LT_SCOPE thing has always struck me as fishy (if only
> because you have only one #define for what may be two different things).

> > 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.

--
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support