[GE users] Linux DRMAA library dependencies

Piotr Domagalski szalik at szalik.net
Sun May 21 00:05:56 BST 2006

    [ The following text is in the "iso-8859-2" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

On Sat, May 20, 2006 at 02:59:52PM +0200, Andreas Haas wrote:

> Hm ... I encounter under Darwin there seems to be generally no -lpthread
> dependency. Here is old/new linking ldd for test_drmaa_perf
> [...]
> note in both cases -lpthread is used at linking stage since test_drmaa_perf
> is multithreaded application code.

Does that mean, that on Darwin even though shared lib has its
dependencies, the application using it still has to link with these
depends explicitly?

> Does your application code itself use pthread_*() calls?
> Where does it crash: in application code or in library code?

The thing is that the order of linking is important, probably to some
runtime linker reallocation magic... It took me some time to track it
down, because for example pthread_create wokred, but crashes happend on

So, briefly, on FreeBSD this kind of linking makes pthreads crash:

gcc -lc -lpthread 

If I make a library that uses pthreads internally and then link an
application against it not using -lpthread the effect is the same,

neutrino% ldd -a a.out
        libfoo.so => /home/szalik/test-thr/libfoo.so (0x28077000)
        libc.so.6 => /lib/libc.so.6 (0x28079000)
        libpthread.so.2 => /usr/lib/libpthread.so.2 (0x28162000)

As you see libpthread is linked because libfoo depends on it but libc is
used before pthreads -- the program crashes.

> In terms of standard definition I see no general issue with having
> different libraries to be specified at application linking stage for
> different OSes: DRMAA compliance testsuite allows to absorb it. An
> issue it would be only, if DRMAA applications would inherit some
> shared library dependency which can not be fulfilled easily at
> deployment time and -dl and -lpthread for sure are unproblematic.

I 100% agree with you.

The main reason I brought this subject up was the -ldl thing which is
Linux specific and it's was another os-dependant issue I had to
remember about when using DRMAA lib with Linux/FreeBSD/Solaris.

Also, another issue -- any particular reason (besides portability of
linker options) that DRMAA shared lib hasn't got `soname' asigned? 

from man ld:

	   When creating an ELF shared  object,  set  the  internal
DT_SONAME field  to  the specified name.  When an executable is linked
with a shared object which has a DT_SONAME field, then when the
executable is  run  the  dynamic linker will attempt to load the shared
object specified by the DT_SONAME field rather than  the  using  the
file name given to the linker.

I think this might become handy when SGE will be switching from default
libdrmaa.0.95.so to libdrmaa.1.0.so, because now applications are really
linked to libdrmaa.so (not libdrmaa.x.x.so) and after changing the
symbolic link, runtime linker will use the new library.

Piotr Domagalski

To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list