Board index Solaris

Java/Fortran/Shared Libraries

Java/Fortran/Shared Libraries

Post by Margaret Mahone » Thu, 07 Jan 1999 04:00:00



Subject: Dynamic Linker - PLT unresolved symbols

I am creating a shared library for use in a Java application.

I have a Fortran algorithm consisting of a number of subroutines
which will be call by a C wrapper.

After making a shared library of all these routines, I  wanted to
test this library.

All modules were compiled with a -g and -KPIC option. The library
was created using the f77 linker so that all Fortran symbols were
resolved. Linker options -g, -G and -nolib were invoked and all
libraries were linked in after all application modules were loaded.

I  have a test program in C that will call the C wrapper and exercise
the
algorithms. The algorithm makes use of client/server calls which are
found in the /usr/lib/libnsl.so.1 library.

Using ldd on the test program shows that /usr/lib/libnsl.so.1 is
preloaded.
The object of interest is the function 'clnt_create'.

I can run this test program through the de* and successfully access

all the Fortran modules in the new shared library.

One of the Fortran modules calls 'clnt_create'. This symbol is
unresolved in
the Procedure Linkage table (PLT) even though this library
(/usr/lib/libnsl.so.1)
was preloaded. An 'nm' on the library shows that the symbol is defined.

Can anyone give my any clues as to why the PLT isn't correct and why I
can't
open the 'clnt_create' object. I'm probably going to have the same
problem with
other similar system calls.

I would gratefully appreciate any insights.

Peg Mahoney

p.s. platform is SunOS 5.5.1

 
 
 
Top

Java/Fortran/Shared Libraries

Post by Robert Corbe » Fri, 08 Jan 1999 04:00:00




Quote:>Subject: Dynamic Linker - PLT unresolved symbols

>I  have a test program in C that will call the C wrapper and exercise
>the
>algorithms. The algorithm makes use of client/server calls which are
>found in the /usr/lib/libnsl.so.1 library.

>Using ldd on the test program shows that /usr/lib/libnsl.so.1 is
>preloaded.
>The object of interest is the function 'clnt_create'.

>I can run this test program through the de* and successfully access

>all the Fortran modules in the new shared library.

>One of the Fortran modules calls 'clnt_create'. This symbol is
>unresolved in
>the Procedure Linkage table (PLT) even though this library
>(/usr/lib/libnsl.so.1)
>was preloaded. An 'nm' on the library shows that the symbol is defined.

>Can anyone give my any clues as to why the PLT isn't correct and why I
>can't
>open the 'clnt_create' object. I'm probably going to have the same
>problem with
>other similar system calls.

>I would gratefully appreciate any insights.

>Peg Mahoney

Is the routine clnt_create called directly from Fortran code?
By default, Sun Fortran appends a low line to the end of names
to avoid clashes with C names.

                                        Sincerely,
                                        Bob Corbett

 
 
 
Top

1. FORTRAN common in AIX shared library not shared at runtime (0/1)

We got following problem in accessing a FORTRAN Common within a
shared library.

The task is to put an FORTRAN common in a shared library and access
this common from:

a) routines which resides inside the shared library
b) routines statically linked to an executable which uses the shared
   library at runtime

At link time of the shared library we use the -bE: -bM:SRE and
-bnoentry flags. The export list used with the -bE: flag contains
the FORTRAN common to be shared. The problem at runtime is, it seems
as if the FORTRAN common is not shared between the routines in the
shared library and the routines in the executable.

I add an (already shortened) example which demonstrates the problem.
The example exists of:
                                              source        location
--------------------------------------------------------------------
FORTRAN common SLCOM                          sl_common.inc       SL
FORTRAN routine SL_BLOCKDATA initial. SLCOM   sl_blockdata.f      SL
FORTRAN routine PRINT_COM printing SLCOM      print_com.f         SL
C global variables STRING, STRUKTUR           sl_globals.h        SL
C routine print_glob printing C globals       print_glob.c        SL
FORTRAN routine PRINT_COM_LOC printing SLCOM  print_com_loc.f    EXE
C routine print_glob_loc printing C globals   print_glob_loc.c   EXE
C main() routine                              main.c             EXE

The main() routine just prints the contents of the FORTRAN common
and C globals via the corresponding shared library and "local"
print_XXX() routines. The resulting output demonstrates, that the C
globals are shared and the FORTRAN common is duplicated (watch the
printed memory addresses).

Has anybody else experienced this problem and solved it? We are
running AIX 4.1 on an IBM RS600 40S system.

Thanx Guenter.

P.S. Source code of the mentioned example is attached. You only have
to save all files in one directory and call make.

2. Lotus Notes on 2.5.1?

3. Need help with Tcl7.6/Tk4.2, gcc, FORTRAN/C/C++ shared libraries (LONG)

4. Running format in a script to label a lot of disks ...

5. ld.so not finding fortran shared libraries

6. Help! User's mail file getting trashed ...

7. C calling Fortran 77 shared library on OSF/1 (or DUnix ?)

8. Will strip(debug shared library) == nodebug shared library ?

9. Help with building shared libraries with dependencies on other shared libraries

10. Question: Inclusion of shared libraries during linking of shared libraries

11. Shared library loading shared library.

12. Need a Shared Library Guru: beyond simple shared library question


All times are UTC
Board index