Opened 15 years ago

Closed 11 years ago

#358 closed defect (fixed)

IZ2059: shared library name DT_SONAME not set with

Reported by: andreas Owned by:
Priority: normal Milestone:
Component: sge Version: 6.0
Severity: minor Keywords: drmaa


[Imported from gridengine issuezilla]

        Issue #:      2059             Platform:     All      Reporter: andreas (andreas)
       Component:     gridengine          OS:        All
     Subcomponent:    drmaa            Version:      6.0         CC:    None defined
        Status:       STARTED          Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    templedf (templedf)
      QA Contact:     templedf
       * Summary:     shared library name DT_SONAME not set with
   Status whiteboard:

     Issue 2059 blocks:
   Votes for issue 2059:

   Opened: Tue May 23 07:57:00 -0700 2006 

Under Linux there is a ld(1) option

  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.

for setting a shared libraries DT_SONAME.

An application linked with a shared library with DT_SONAME
can detect at deployment time, if the library in LD_LIBRARY_PATH
has the right version. Without DT_SONAME being set it can occur
the application starts though, but shows strange error behaviour
during run-time.

Until now (6.0u8) delivered with N1GE is of version 0.95.
It is planned though to deliver in future releases a DRMAA 1.0 library
*plus* the old 0.95 compliant one.

As workaround the application shall use drmaa_version() to ensure
LD_LIBRARY_PATH has the correct version.

   ------- Additional comments from andreas Tue May 23 08:20:43 -0700 2006 -------
There is a related problem with 0.95/1.0:

I just encountered (maintrunk) even had linking

   int drmaa_get_num_attr_names(drmaa_attr_names_t* values, int *size);
   int drmaa_get_num_attr_values(drmaa_attr_values_t* values, int *size);
   int drmaa_get_num_job_ids(drmaa_job_ids_t* values, int *size);

even though these functions actually are DRMAA 1.0 specific. I fixed
it (maintrunk). Now at least DRMAA 1.0 applications will fail with a
more reasonable error message, in case LD_LIBRARY_PATH libdrmaa is 0.95.

   ------- Additional comments from andreas Tue May 23 09:03:20 -0700 2006 -------
Added URL to thread with details on how to solve the -soname issue.

   ------- Additional comments from andreas Mon May 29 00:28:05 -0700 2006 -------
Fixed for in Maintrunk and S2-branch for Solaris and Linux

Change History (1)

comment:1 Changed 11 years ago by dlove

  • Resolution set to fixed
  • Severity set to minor
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.