Greetings.
I'm a longtime Libtool user; we've used both Libtool and libltdl in LAM/MPI
and Open MPI (among dozens of other packages!). I've said it before, but
I'll say it again -- thanks bunches for Libtool! I have no idea what we'd
do without it (and for all the help that Ralf W. and others ha
On Wed, 6 Sep 2006, Jeff Squyres wrote:
Greetings.
I'm a longtime Libtool user; we've used both Libtool and libltdl in LAM/MPI
and Open MPI (among dozens of other packages!). I've said it before, but
I'll say it again -- thanks bunches for Libtool! I have no idea what we'd
do without it (and
Hello Jeff, all,
* Jeff Squyres wrote on Wed, Sep 06, 2006 at 04:17:33PM CEST:
>
> The situation is as follows:
>
> 1. Open MPI has a plugin (call it "ompi_plugin") that is linked against a
> shared library ("libibverbs.so").
>
> 2. At run time, ompi_plugin is lt_dlopen()'ed by the OMPI core.
>
On Wed, 6 Sep 2006, Ralf Wildenhues wrote:
I concur with Bob; about a handful of packages that need it one way or
the other (after all, it was changed not only for cleanliness, but
because some packages needed it changed).
We could add another interface
lt_dlopen_flags (const char *filename, i
On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote:
We could add another interface
lt_dlopen_flags (const char *filename, int flags);
I'd prefer to be more specific - lt_dlopen_global(const char * filename)
The docs would specify that it would attempt to open it in the global
namespace,
On Thu, 7 Sep 2006, Peter O'Gorman wrote:
On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote:
We could add another interface
lt_dlopen_flags (const char *filename, int flags);
I'd prefer to be more specific - lt_dlopen_global(const char * filename)
The docs would specify that it would at
On Sep 7, 2006, at 12:37 AM, Bob Friesenhahn wrote:
On Thu, 7 Sep 2006, Peter O'Gorman wrote:
On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote:
We could add another interface
lt_dlopen_flags (const char *filename, int flags);
I'd prefer to be more specific - lt_dlopen_global(const char
I am having a problem with libltdl version 1.5.22 (Ubuntu 6.06) that I
am not having with libltdl version 1.5.16 (Fedora Core 4), and I'm not
sure why. At runtime my program runs into unresolved symbols and
crashes in the middle of running because it can't find a particular
symbol which exists
* Bob Friesenhahn wrote on Wed, Sep 06, 2006 at 05:37:20PM CEST:
> On Thu, 7 Sep 2006, Peter O'Gorman wrote:
> >On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote:
> >>
> >>We could add another interface
> >> lt_dlopen_flags (const char *filename, int flags);
> >>
> >I'd prefer to be more specific
Danny Smith wrote:
>
> ...
> there is no need any more for this warning. gcc should remove this
> warning.
>
>
> Are you sure about that.
>
> The reason that gcc emits these warnings is this:
> gcc -S dllimp.c
>
> .file "dllimp.c"
> .text
> .globl _externfunc2
> .def_ex
On Wed, 6 Sep 2006, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Wed, Sep 06, 2006 at 05:37:20PM CEST:
On Thu, 7 Sep 2006, Peter O'Gorman wrote:
On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote:
We could add another interface
lt_dlopen_flags (const char *filename, int flags);
I'd p
Hello,
Markus Duft wrote:
> I implemented wgcc (a compiler wrapper behaving like gcc but calling
> cl.exe). Since the target should be to compile sources with minimum
> changes i have done lot's of work for this.
That's certainly a good idea. I would consider such a tool usable only
if it had no
Hello Ralf,
> Slightly related question: are you planning on providing a means to
> automatically rename gnulib functions to a library-specific namespace?
> As long as there is no policy on interface stability for gnulib, I would
> fear to see lots of libraries floating around that all carry some
On 9/6/06 11:10 AM, "Ralf Wildenhues" <[EMAIL PROTECTED]> wrote:
> First let me try to point out a workaround for your specific situation:
>
> Since mthca.so is Linux-specific, we can rely on having dlopen available
> for the workaround. Since I assume you would rather not have to modify
> the p
Hello Ralf,
> | Woe32 problem 1: Exports
> [...]
> | Methods 2b and 2c don't work for C++, because of the name mangling.
>
> Well, that assumes that you create an export list (or the asm
> statements) manually.
Yes, that's what I meant by "a selected set of symbols".
> That does not have to be
> gcc reports warnings:
>
> warning: 'externvar' defined locally after being referenced
> with dllimport linkage
> warning: 'externfunc' defined locally after being referenced
> with dllimport linkage
>
> Once libtool is changed to not cause link errors for
> self-references, there is no need
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
>
> Another version. Patch against branch-1-5 only. I've reordered where
> --export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks the
Does -dlopen self work on AIX? While building epiphany-1.6.5 on this
platform, seems that not all the correct symbols are being exported.
On AIX 5.3, dlopen_self=no. If -dlopen self is specified, then the
following code is executed (from the 1.5 branch):
if test "$dlself" = yes; then
No. __declspec(dllimport) tells the compiler that an indirection is
needed. The compiler will simplify '&externvar' to '_imp__externvar'.
There is one _imp__externvar per library, but all their values are the
same.
The "same function name, different address" problem will occur - as far
as I und
19 matches
Mail list logo
