libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Win32 libltdl issue


From: Ralf Wildenhues
Subject: Re: Win32 libltdl issue
Date: Wed, 27 Apr 2005 17:26:26 +0200
User-agent: Mutt/1.4.1i

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]