Problems in building shared library

91 views
Skip to first unread message

Ram

unread,
May 28, 2008, 12:14:49 AM5/28/08
to jBASE
Hi,

Iam trying to build a shared library (libmyshared.so) that uses
functions in a third party archive library (libcus.a). I used jcompile
to compile the C code (jb_cus.c, that uses functions of libcus.a) with
the following options,

jcompile -olibmyshared.so jb_cus.c /appl/swift/libcus.a

There are no problems with compilation, however the CALLC from the jBC
routine fails with the following runtime error, cus_init being one of
the functions in libcus.a.

rtld: 0712-001 Symbol cus_init was referenced
from module /data1/bnk/bnk.run/lib/libmyshared.so(), but a
runtime definition
of the symbol was not found.
....

I have set the LIBPATH and LD_LIBRARY_PATH to point to /appl/swift
(directory containing archive library), it does not help either. Is
there a different option to be used in jcompile to include functions
in an archive library?

Thanks in advance for your feedback

Best Regards
Ram
AIX 5.3, jBASE 5.0


jdiag

System Information
==================

System : AIX
OS Release : 5.3.0.0
UNIX User : Unknown (uid 24, euid 24)
Tty name : /dev/pts/13
Time : Wed May 28 11:40:18 2008

Environment
===========

JBCPORTNO : Not Set
JBCRELEASEDIR : '/app/jbase50'
JBCGLOBALDIR : '/app/jbase50'
HOME : '/data1/bnk/bnk.run'
JEDIFILEPATH : '/data1/bnk/bnk.run'
JEDIFILENAME_MD : '/data1/bnk/bnk.run/VOC'
JEDIFILENAME_SYSTEM : '/app/jbase50/src/SYSTEM'
SYSTEM File is (DICT) : '/app/jbase50/src/SYSTEM]D'
RELEASE Information : Major 5.0 , Minor 7 , Patch 0170 (Change
59887)
Spooler dir (JBCSPOOLERDIR) : '/data1/bnk/bnk.run/jspooler'
JBCEMULATE : 'prime'
Object path (JBCOBJECTLIST) : /data1/bnk/bnk.run/lib:/data1/bnk/
bnk.run/globuspatchlib:/data1/bnk/bnk.run/globuslib
jBASE Compiler Run-time : '/app/jbase50/config/system.properties'
Program dir (JBCDEV_BIN) : '/data1/bnk/bnk.run/bin'
Subroutine dir (JBCDEV_LIB) : '/data1/bnk/bnk.run/lib'
Max open files : 65534

Jim Idle

unread,
May 28, 2008, 10:59:41 AM5/28/08
to jB...@googlegroups.com
On Tue, 2008-05-27 at 21:14 -0700, Ram wrote:
Hi,

Iam trying to build a shared library (libmyshared.so) that uses
functions in a third party archive library (libcus.a). I used jcompile
to compile the C code (jb_cus.c, that uses functions of libcus.a) with
the following options,

jcompile -olibmyshared.so jb_cus.c /appl/swift/libcus.a

There are no problems with compilation, however the CALLC from the jBC
routine fails with the following runtime error, cus_init being one of
the functions in libcus.a.

rtld: 0712-001 Symbol cus_init was referenced
      from module /data1/bnk/bnk.run/lib/libmyshared.so(), but a
runtime definition
      of the symbol was not found.
....

I have set the LIBPATH and LD_LIBRARY_PATH to point to /appl/swift
(directory containing archive library), it does not help either. Is
there a different option to be used in jcompile to include functions
in an archive library?

Thanks in advance for your feedback

Best Regards
Ram
AIX 5.3, jBASE 5.0

Just before the CALLC, print out the value of the environment variable LIBPATH and make sure it is still valid.

However:

1) Is libcus.a actually a shared library, or is it an archive library? I suspect that adding the library to the jcompile like that isn't going to do what you want (it might be that you have to use -lcus), but on 5.3 I think you have the ldd command (if not you will have to use the dump command to find the same information). If you use:

ldd ./libmyshared,so

Does it tell you that it is looking for libcus?

2) It is possible that you have a library in some older format that won't load in the same way as newly compiled libraries (for instance it might not be loaded in to your global symbol space when the CALLC loads libmyshared.so, even if it appears to be referenced, because of various options in dlopen() [or equivalent] that don't work quite like they should on AIX. What does nm tell you about libcus.a? Does it contain cus_init()

3) What does ldd ./libcus.a tell you about its dependencies? When you load a dynamic library with CALLC it may not be able to load dependent libraries, but it will fail silently until you try to reference the symbol. Make sure all the references are there.

4) Try compiling the main program with a reference to -L/your path -L /swift path -lmyshared -lcus, does that resolve the issue? If you have just one or two main programs that reference the libraries, then I would compile using those references directly and declare the functions with DEFC, as this will generally be faster.

5) Try a small C program that just does a dlopen on the two libraries, then attempts to resolve the symbol cus_init. Does the behavior change when you change the flags given to the library loading function?


Jim

Ram

unread,
May 29, 2008, 6:27:26 AM5/29/08
to jBASE
Hi Jim,

Thanks a lot for your response.

"libcus.a" is an archive library, I tried jcompile with -l option,
however "ldd" does not seem to list libcus.a as one of its
dependencies.

jsh ---> jcompile jb_CASmf.c -L/appl/T24/jbase50/lib -lcus -d -s
libmyshared.so

# ldd libmyshared.so
libmyshared.so needs:
/appl/T24/jbase50/lib/libjbase.so
/appl/T24/jbase50/lib/libjbaseutil.so
/usr/ccs/lib/libc.a(shr_64.o)
/usr/ccs/lib/libcurses.a(shr42_64.o)
/usr/lib/libC.a(shr_64.o)
/usr/lib/libC.a(shr2_64.o)
/usr/lib/libC.a(shr3_64.o)
/usr/lib/libC.a(ansi_64.o)
....

When I tried to run "nm" or "dump" with 64 bit option for the static
library (nm -X64 libcus.a / dump -X64 -o libcus.a), there is no
output. However with the 32 bit option all symbols are listed.

So I guess 'libcus.a' contains only 32 bit objects, and hence there is
a problem in linking this with a 64 bit dynamic library. Is this
assumption correct?

Thanks in advance for your feedback.

Best Regards
Ram
> Jim- Hide quoted text -
>
> - Show quoted text -

Jim Idle

unread,
May 30, 2008, 12:48:40 AM5/30/08
to jB...@googlegroups.com
On Thu, 2008-05-29 at 03:27 -0700, Ram wrote:
Hi Jim,

Thanks a lot for your response.

"libcus.a" is an archive library, I tried jcompile with -l option,
however "ldd" does not seem to list libcus.a as one of its
dependencies.

If it is an archive library, then you will need to build it into the calling programs rather than the shared library unless the shared library is guaranteed to reference all the symbols of the archive.

One thing you could do is unarchive the object files in the .a file then create a shared object:

mkdir tmp ; cd tmp
ar -x libcus.a
jcompile *.o -o libcus.so

Also, what do you get if you try:

jcompile libcus.a -o libcus.so

Use the nm command to check the symbols contined in the libraries you are building.

jsh ---> jcompile jb_CASmf.c -L/appl/T24/jbase50/lib -lcus -d -s
libmyshared.so

As it is not a shared library, then the archive elements will either be placed in the resulting shared library, or perhaps just ignored. Are you sure it is an archive and not an AIX archive of a shared library?



# ldd libmyshared.so
libmyshared.so needs:
         /appl/T24/jbase50/lib/libjbase.so
         /appl/T24/jbase50/lib/libjbaseutil.so
         /usr/ccs/lib/libc.a(shr_64.o)
         /usr/ccs/lib/libcurses.a(shr42_64.o)
         /usr/lib/libC.a(shr_64.o)
         /usr/lib/libC.a(shr2_64.o)
         /usr/lib/libC.a(shr3_64.o)
         /usr/lib/libC.a(ansi_64.o)
         ....

When I tried to run "nm" or "dump" with 64 bit option for the static
library (nm -X64 libcus.a / dump -X64 -o libcus.a), there is no
output. However with the 32 bit option all symbols are listed.

So I guess 'libcus.a' contains only 32 bit objects, and hence there is
a problem in linking this with a 64 bit dynamic library. Is this
assumption correct?

Yes - if it is a 32 bit library, you won't be able to link it with a 64 bit object and that is likely your problem. You need to get a 64 bit version.

Thanks in advance for your feedback.

No problem - I hope it works out for you.

Jim
Reply all
Reply to author
Forward
0 new messages