Prev: How long does read(2) wait before an EAGAIN is thrown?
Next: writev() on a SOCK_STREAM socket
From: Andrea Bertoni on 19 Jun 2008 14:30
Hello to everybody,
I'm wondering if someone can show me a workaround to the following
problem I'm fighting with.

In my program I need to use two libraries: ARPACK and PARDISO.
Both of them make (internal) use of a third library, namely LAPACK.
Unfortunately they use a different version of this library.

I have the src code of ARPACK, that include the src of LAPACKv2. I
compile them.
In order to work, PARDISO need to link LAPACKv3. The two are bins in
the intel mkl package.

When I link my code with ARPACK and PARDISO (and LAPACKv3) I get a lot
of
"multiple definition of _", quite reasonable.

....but I don't know how to solve the problem.
I mean, is there a way to tell the linker that the calls to LAPACK
routines inside arpack.a are to be resolved using the objects inside
the arpack.a itself, and at the same time to say that the calls from
PARDISO are to be resolved by another specific library (lapack_v3.a)
and not by the LAPACKv2 routines inside arpack.a ??

It seems to me that it should be a very common problem, by I wasn't
abale to find anything about that...

Thanks in advance of anything you can suggest.
Andrea
From: Thomas Maier-Komor on 20 Jun 2008 01:46
Andrea Bertoni schrieb:
> Hello to everybody,
> I'm wondering if someone can show me a workaround to the following
> problem I'm fighting with.
>
> In my program I need to use two libraries: ARPACK and PARDISO.
> Both of them make (internal) use of a third library, namely LAPACK.
> Unfortunately they use a different version of this library.
>
> I have the src code of ARPACK, that include the src of LAPACKv2. I
> compile them.
> In order to work, PARDISO need to link LAPACKv3. The two are bins in
> the intel mkl package.
>
> When I link my code with ARPACK and PARDISO (and LAPACKv3) I get a lot
> of
> "multiple definition of _", quite reasonable.
>
> ...but I don't know how to solve the problem.
> I mean, is there a way to tell the linker that the calls to LAPACK
> routines inside arpack.a are to be resolved using the objects inside
> the arpack.a itself, and at the same time to say that the calls from
> PARDISO are to be resolved by another specific library (lapack_v3.a)
> and not by the LAPACKv2 routines inside arpack.a ??
>
> It seems to me that it should be a very common problem, by I wasn't
> abale to find anything about that...
>
> Thanks in advance of anything you can suggest.
> Andrea

compile both arpack and pardiso as shared libraries instead as static
ones and link them as needed to lapack. Like this, when you link both of
them into your program, their dependencies will be resolved
automatically. I.e. only if you need lapack v2 or v3 in your program,
too, you'll need to link to it. Otherwise it will be unnecessary to link
your program to lapack, and both shared libraries will picked up as needed.

To make sure everything is set up correctly, you can use ldd to display
which shared libraries will be used by every shared library and your
program. E.g.
$ ldd /usr/lib/libarpack.so
$ ldd /usr/lib/libpardiso.so
$ ldd ./my_program

HTH,
Thomas
From: Paul Pluzhnikov on 20 Jun 2008 02:19
Andrea Bertoni <commenda(a)gmail.com> writes:

> "multiple definition of _", quite reasonable.
>
> ...but I don't know how to solve the problem.
> I mean, is there a way to tell the linker that the calls to LAPACK
> routines inside arpack.a are to be resolved using the objects inside
> the arpack.a itself, and at the same time to say that the calls from
> PARDISO are to be resolved by another specific library (lapack_v3.a)
> and not by the LAPACKv2 routines inside arpack.a ??

No.

> It seems to me that it should be a very common problem, by I wasn't
> abale to find anything about that...

It's not a very common problem ...

You would save yourself a world of grief if you can find newer ARPACK
that depends on LAPACKv3 (perhaps you can just fix the source and
send a patch to its maintainer), or older PARDISO, that depends
on LAPACKv2.

If neither is possible, you could probably still make it work by using
'ld -r ...' to link whatever you need from arpack.a into arpack.o,
and then "hiding" all conflicting symbols with 'objcopy --localize-symbols ...',
before linking the final executable.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
From: Thomas Maier-Komor on 20 Jun 2008 02:47
Shankar Kalpathi Easwaran schrieb:
> There is an option -z muldefs which you can provide to the linker where
> it would ignore multiple definitions..
>
> --
>
> Shankar K E
>

and what would be the result in this case? The man page says:
-z muldefs

Allows multiple symbol definitions. By default, multiple
symbol definitions that occur between relocatable
objects result in a fatal error condition. This option,
suppresses the error condition, allowing the first sym-
bol definition to be taken.

So, I guess this option is for situations where all definitions are in
fact identical, rather than differing ones. Here every instance is needed...

- Thomas
From: Paul Pluzhnikov on 20 Jun 2008 02:32
Thomas Maier-Komor <thomas(a)maier-komor.de> writes:

> compile both arpack and pardiso as shared libraries instead as static
> ones and link them as needed to lapack. Like this, when you link both
> of them into your program, their dependencies will be resolved
> automatically.

Not on any UNIX other than AIX.

By default, given conflicting symbols in liblapack.so.2 and
liblapack.so.3, one of them will override the other at runtime,
with a crash as most likely outcome.

This can be made to work with symbol versioning (Linux), with
-Bsymbolic linking, or some other platform-specific hackery,
but it is quite unlikely to work "by default" on many OSes.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
 |  Next  |  Last
Pages: 1 2
Prev: How long does read(2) wait before an EAGAIN is thrown?
Next: writev() on a SOCK_STREAM socket