Creating a shared object

[devshlom]

Hi,

I just want to be sure of something that was mentioned before:
is "+z" is the the equivalent for "-fPIC" for HPUX compiler?!
=> the "+z" will compiled the code position independent?


tx

[devshlom]

and another question:

For all the other platform, I managed to create the shared lib without using the "-fpic" - only for HP-UX this was the only thing that fix the "invalis fix loader..." link error I got.

Do you have any clue why it worked for me for all the other unix platforms (with PIC) and here I'm required?? (is it something I missing here - or just a different and acceptable behavior?!)

tx,
shlom

[Dennis Handly]

>is "+z" is the the equivalent for "-fPIC" for HP-UX compiler?! the "+z" will compiled the code position independent?

I'm not sure which is +z and which is +Z. Try "-fpic" first.

>I managed to create the shared lib without using the "-fpic" - only for HP-UX this was ...
>Do you have any clue why it worked for me for all the other unix platforms (with PIC) and here I'm required??

Not sure. On IPF, +z/+Z is obsolete and the default is PIC. But for gcc is may not be.

>just a different and acceptable behavior?

Naturally. :-)
Non-PIC code is faster and better for executables.

[devshlom]

I had a mistake on the second question - here is the correct one:
I'm trying to understand how I managed to create shared lib successfully WITHOUT "-fpic" in all the other UNIX platforms.
Actually I need to know:
1.Why only the HP-UX enforce me using the PIC?
2. For my knoladge, is there any way to create a shared lib in HPUX without compiling position independent objects at all?!

tx

[Dennis Handly]

>1.Why only the HP-UX enforce me using the PIC?

The IPF HP-UX default is PIC, probably because of this. But I believe IPF Linux also defaults to non-PIC.
The HP-UX PA32 decision was made over 23+ years when there weren't shlibs on HP-UX.

>2. is there any way to create a shared lib in HP-UX without compiling position independent objects at all?

Of course not. PIC is required by shlibs. The whole purpose of a shlib is to map it in memory at any location and be used by many executables, both which needs PIC.

[devshlom]

Hi,

I added the "-fpic" to all the libs the my sl is being linked with and this solved the problem!!!
Now I have some running problems, but this is for a different thread.

tx all for the good answers.

shlom

[Vineet K. Aggarwal]

I know this thread is closed, but I have a question for Dennis along the same lines I am hoping he can answer.

In response to the previous question:

"I will have to change the extension to "sl" - don't I?"

the response was:

"You don't "have" to but it is a good idea.
Otherwise ld won't find it with -ltest without extra work."

My application (for reasons I won't go into) depends on the shared library extensions to end in .so. As such, I don't want to change them to .sl. Can you please explain to me what "extra work" I need to do to make ld find my .so files? Right now, it can't find them unless I rename them to .sl.

Thank you so much!

[Dennis Handly]

>ME: On PA you use .sl. On IPF you use .sl.

Oops, I don't know if this confused anyone but this should say:
On PA you use .sl. On IPF you use .so.

>Vineet: I know this thread is closed, but I have a question

You should create your own thread so you can assign points and if useful include a URL to point to this thread.

>I don't want to change them to .sl. Can you please explain to me what "extra work" I need to do to make ld find my .so files?

You could do two things:
1) Create a symlink that points the .sl to the .so.
2) Change your link line to have: -l:libtest.so

[Vineet K. Aggarwal]

Sorry about not creating a new thread -- I wanted you specifically to respond, so I wasn't sure if you would see my new thread otherwise. I will do that for sure next time.

As for your suggestion, I actually tried to use -l:, but it didn't work. I suspect this is because of the last sentence in the following excerpt from a doc on ld:

-l: library Search the library specified. Similar to the -l option except the current state of the -a option is not important. The library name must contain the prefix lib and end with a suffix of .a or .sl.

I got this from:
http://www.informatik.uni-frankfurt.de/doc/man/hpux/ld.1.html

I think it will only look for .a or .sl...

[Dennis Handly]

>Vineet: I actually tried to use -l:, but it didn't work.

I have no problems with: -L. -l:libfoo.so

>I suspect this is because of the last sentence in the following excerpt from a doc on ld:

Only the recommended/official suffixes are listed. But your issue could be due to the change in the linker. ld(1) now says:
The library name can be any valid filename. (Note that previous releases required that the library name contain the prefix lib and end with a suffix of .a or .sl.)