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
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 call to remctl_new(), which returns a
pointer to i
14 matches
Mail list logo
