shl_load function

[lara]

Hi,

I have a static library ( xyz.a ) which is linked to the main program test.cpp. The main function opens a shared library libabc.sl which calls the function xyz() defined in xyz.a If I compile the code as below, it fails to export the symbol xyz and returns a runtime
error( unable to load the shared library due to undefined symbols ).

/opt/aCC/bin/aCC -o c.out test.o xyz.a -lc

I tried exporting all the symbols using -Wl,-E option, but still get the same error.

However, instead of creating the static library xyz.a, if I create an object file
(say xyz.o ) and try to link the code, it works fine.

Does anyone know how to link the code as a library and export the symbols so that it works without any problem.

( I have also tried using -WI,+ee option, but
the compiler gives an error( error no. 1913 ) " does not exist or cannot be read"

[Vincent Fleming]

Your posting is a little unclear to me (and I'm a little rusty at this), but I think I know what your problem is...

When you link with the library xyz.a like this:

>aCC -o c.out test.o xyz.a -lc

and the xyz() function (defined in xyz.a) is called from a shared library (libabc.sl), I think the linker would not load xyz.a because there is no direct link to it in test.o. (ie: it's not examining libabc.sl because you didn't list "-labc" (or libabc.sl) on the aCC command line, so it's not getting the call to xyz())

Wow - that's a mouthful! Maybe this is clearer:
in test.c, main() calls blah() in libabc.sl
in libabc.sl, blah() calls xyz() in xyz.a

So, on the link line, you would need to list them in that order: main, libabc.sl, xyz.a

I gather that libabc.sl is not a System library (you wrote it), so why not just put the xyz() function in there? Or include -labc on the command line [prior to xyz.a - as I recall, this is a single-pass linker].

Here's an example command line:
aCC -o c.out test.o -labc xyz.a -lc

Clear as mud?

Good luck!

[lara]

Hi Vincent,

Your description of the problem is correct

"in test.c, main() calls blah() in libabc.sl
in libabc.sl, blah() calls xyz() in xyz.a "

The issue is that libabc.sl is created by the user of the tool( say in this case c.out ) to link his code to the tool. So libabc.sl is not know at compile time.( The user uses a set of API functions to interface with the tool ).

xyz.a contains the API function definitions.

One solution would be not to create a xyz.a library but instead link the object files, but I am looking for a solution where I can link it as a library.

Also I created a simple testcase for the above problem. When I used cc to compile and link( with -Wl,-u -Wl,+ee ), it worked fine. However, if I use aCC to the same testcase, it doesn't work.
Hope this makes the problem more clearer

[Vincent Fleming]

It's the same problem...

When the linker performs the link, it passes through each file listed in the command line, in the order listed.

The undefined symbols located in the .o files are gathered, and it searches through the libraries (in the order listed) looking to resolve them. If you haven't referenced xyz() in the .o's, the linker will not include it in the a.out. (which is the whole idea of putting it in a library to start with - the linker picks out only what it needs - and it doesn't know that you need xyz at the time) [This is different than listing xyz.o on the command line, because the linker *must* include xyz.o in the a.out (even if you didn't reference xyz(), because you told it to by listing the .o on the command line.]

When you dynamically load libabc.sl, xyz() is not present if it was in the .a, but is present if you use the .o.

Basically, if you dynamically load the library, it's up to you to make absolutely sure that the function [xyz()] is part of your program.

...I guess you could make an xyz.sl that you could dynamically load just before dynamically loading libabc.sl... which should work. But you cannot use a .a unless you somehow reference xyz() from a .o.

Perhaps a forward reference to the function would be good enough to cause the linker to include the function in the link... such as in your main.c, add:

static int xyz();

in the declarations section (global scope).

I would have to try that one, though...

It seems to me that how you end up doing this really depends on how modular you want to keep the program.

Good luck!

[Mike Stroyan · Accepted solution]

Here are a couple of options.

You can use
aCC -o c.out test.o -Wl,-u,xyz xyz.a
to make xyz undefined so it will be pulled in from xyz.a. (You should not link with -lc. Let aCC put libc in the link sequence where it belongs.)

You can use
aCC -o c.out test.o -Wl,-Fl,xyz.a
to force load all of xyz.a.
The 64 bit PA or IPF linker wants
aCC +DD64 -o c.out test.o -Wl,+forceload,xyz.a

[lara]

Hi Vincent & Mike,

Thanks for your suggestion. The option of forcing the library to be loaded worked. I
tried the other options of foward referencing and using the -u option, but for some reason they did not work. Even when I forced the library to be loaded, I had to use -Wl,-E option to export the symbol or otherwise it would not recongize it. I had to use the -E option since when I used -Wl,+ee xyz the compiler gave the following error "aCC: error 1913: `xyz' does not exist or cannot be read

[lara]

Hi,

I figured out that there shouldn't be any space between +ee and symbol or should use "," and the symbol name for aCC to pass the argument without any error to ld