On 17-05-13 02:35, Russ Allbery wrote:
> I have a C shared library that takes a pointer to an opaque struct as the
> first argument to most of its API calls. The internal layout of that
> opaque struct is changing (to add new members). The only way to create
> the opaque state struct is via a cal
Le 17/05/2013 15:45, Chow Loong Jin a écrit :
But how do you load a plugin without using dlopen()?
> [...]
> Okay, so real shared libraries can't be dlopen()'d on some systems, and
> plugins
> still have to be dlopen()'d. That doesn't answer my question, really.
It kind of does, actually :-)
On 17/05/2013 19:50, Simon McVittie wrote:
> On 17/05/13 10:43, Chow Loong Jin wrote:
>> On 17/05/2013 13:17, Guillem Jover wrote:
>>> I agree dlopen()ing shared libraries in general should not be
>>> supported (I'd even go further and say this should be outright
>>> banned, given the pain it caus
Le 17/05/2013 14:18, Sune Vuorela a écrit :
> On 2013-05-17, Simon McVittie wrote:
>> dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I
>> think) are among the platforms where either works, so in practice most
>
> You can't link plugins on windows, I'm told.
Indeed. Some informat
Le 17/05/2013 13:50, Simon McVittie a écrit :
> According to libtool documentation, on some platforms this distinction
> is really significant, and "real shared libraries" can't be
> dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I
> think) are among the platforms where either work
On 2013-05-17, Simon McVittie wrote:
> dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I
> think) are among the platforms where either works, so in practice most
You can't link plugins on windows, I'm told.
/Sune
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
On 17/05/13 10:43, Chow Loong Jin wrote:
> On 17/05/2013 13:17, Guillem Jover wrote:
>> I agree dlopen()ing shared libraries in general should not be
>> supported (I'd even go further and say this should be outright
>> banned, given the pain it causes, and optional library support
>> should always
On 17/05/2013 13:17, Guillem Jover wrote:
> Yeah that should be the case, the dynamic linker should not be
> loading the same SONAME multiple times, so there should be no race
> here, and I agree dlopen()ing shared libraries in general should not
> be supported (I'd even go further and say this sho
Le vendredi 17 mai 2013 07:17:48, Guillem Jover a écrit :
> (…) I agree dlopen()ing shared libraries in general should not
> be supported (I'd even go further and say this should be outright
> banned, given the pain it causes, and optional library support should
> always be implemented by loading a
Josselin Mouette writes:
> Le jeudi 16 mai 2013 à 17:35 -0700, Russ Allbery a écrit :
>> I have a C shared library that takes a pointer to an opaque struct as
>> the first argument to most of its API calls. The internal layout of
>> that opaque struct is changing (to add new members). The only
On Fri, May 17, 2013 at 2:35 AM, Russ Allbery wrote:
> I have a C shared library that takes a pointer to an opaque struct as the
> first argument to most of its API calls. The internal layout of that
> opaque struct is changing (to add new members). The only way to create
> the opaque state stru
Le jeudi 16 mai 2013 à 17:35 -0700, Russ Allbery a écrit :
> I have a C shared library that takes a pointer to an opaque struct as the
> first argument to most of its API calls. The internal layout of that
> opaque struct is changing (to add new members). The only way to create
> the opaque stat
Hi!
On Thu, 2013-05-16 at 17:35:10 -0700, Russ Allbery wrote:
> I have a C shared library that takes a pointer to an opaque struct as the
> first argument to most of its API calls. The internal layout of that
> opaque struct is changing (to add new members). The only way to create
> the opaque s
13 matches
Mail list logo
