Le 06/09/2012 16:10, Bob Friesenhahn a écrit :
> On Tue, 4 Sep 2012, Brice Goglin wrote:
>
>> FYI, I finally found the problem.
>> ltdl symbols are marked as __declspec(dllexport) while my symbols are
>> not. It looks like it causes all my symbols to be hidden after link.
Does anybody know if marking as dllexport could cause other problems?
Thanks
Brice
Le 25/08/2012 10:44, Brice Goglin a écrit :
> Hello,
>
> I have successfully embedded libltdl inside hwloc using the recursive
> thanks to your advice a couple days ago. But I am now trying to see if
&
). We
> made C++ modules that were lt_dlopen'd at runtime.
>
> On Wed, Aug 29, 2012 at 8:02 AM, Brice Goglin <mailto:brice.gog...@inria.fr>> wrote:
>
> Le 29/08/2012 14:50, Robert Boehne a écrit :
>> Are you passing the name of the libtool "la"
Hello,
I cannot get ltdl to load plugins on AIX 6.1. I am compiling plugins
with -module -avoid-version. libtool generates a ".so" but then embeds
it inside a ".a" and it looks like it really wants me to use this ".a"
since the ".so" doesn't even get installed.
When lt_dlopen tries to open the pl
Hello,
I have successfully embedded libltdl inside hwloc using the recursive
thanks to your advice a couple days ago. But I am now trying to see if
that works under windows too. I am seeing something beyond my
understanding. What seems to happen is that linking the ltdl la file
makes my symbols di
Le 22/08/2012 21:05, Nick Bowler a écrit :
> [...]
> Indeed, it looks like LT_CONFIG_H is set using AC_CONFIG_COMMANDS_PRE,
> so it does in fact get set "inside" AC_OUTPUT. I guess you could write
>
> AC_CONFIG_COMMANDS_PRE([LT_CONFIG_H=`expr "$LT_CONFIG_H" : '.*/\(.*\)'`])
>
> and hope that it
Le 22/08/2012 19:44, Nick Bowler a écrit :
> On 2012-08-22 18:32 +0200, Brice Goglin wrote:
>> Le 22/08/2012 16:32, Nick Bowler a écrit :
>>> On 2012-08-22 15:12 +0200, Brice Goglin wrote:
>>>> I am working at embedding libltdl inside our project (hwloc, an Open MP
Le 22/08/2012 16:32, Nick Bowler a écrit :
> On 2012-08-22 15:12 +0200, Brice Goglin wrote:
>> I am working at embedding libltdl inside our project (hwloc, an Open MPI
>> subprojet). Our plugins are not expected to be enabled in the most
>> common cases. So I am trying to s
Hello,
I am working at embedding libltdl inside our project (hwloc, an Open MPI
subprojet). Our plugins are not expected to be enabled in the most
common cases. So I am trying to see if the libltdl sub-configure could
be skipped entirely unless really needed (when plugins are enabled, and
libltdl
Le 04/04/2012 00:04, Bob Friesenhahn a écrit :
> On Tue, 3 Apr 2012, Brice Goglin wrote:
>>> It is common for glibc to secretly allocate some memory for its own
>>> use, and this is particularly true for multi-threaded programs. Often
>>> it has no way to safely rele
Le 03/04/2012 23:13, Bob Friesenhahn a écrit :
> On Tue, 3 Apr 2012, Brice Goglin wrote:
>>
>> I am fixing leaks in one of my software projects that embeds libltdl
>> 2.4.2 to load plugins. I noticed that when the plugin depends on the
>> dynamic library that the mai
raries when the
plugin is unloaded. But I'd like to know if these leaks are expected or
not. The good news is that these leaks do not depend on the number of
times this code is executed within the program, so the leaked size
should be constant.
Regards
Brice Goglin
$ valgrind --leak-check=f
12 matches
Mail list logo
