Using chatr to achieve -Bprotected_def?

[Krishna R]

Hi,

I want to add -Bprotected_def to linker options while building my app.

Is there anyway I can use chatr on already built library and achieve the same symbol resolution, instead of rebuilding the application?

Thanks,
krishna

[Dennis Handly · Accepted solution]

-Bprotected_def is a compiler option, not linker.

>use chatr on already built library

No, you must recompile and relink.

There is a -Bsymbolic linker option but this is very dangerous and not supported for C++.

[Krishna R]

Thanks again.

But, can you please explain what is the impact of using -Bsymbolic - why it is considered dangerous.

Also, I would like to know what is the best solution for our problem.

Our app uses a 3rd party library. Our libraries link to libstd.so and the 3rd party library links to libstd_v2.so and our application crashed during initialization of the 3rd.p.l. By asking them, we had the 3rd.p.l relinked with -Bsymbolic and it works fine now.

Can you guys explain which is the best solution in this case?

If I do not have control over how other libraries are built, how can i ensure from my side that the application will work?

[Dennis Handly]

>can you please explain what is the impact of using -Bsymbolic - why it is considered dangerous.

There are certain symbols that must be global in scope, type_info, etc. for proper operation.
Also, you don't get a performance boost as you get with -Bprotected_def.

>I would like to know what is the best solution for our problem.

As documented, the correct solution is to port your application to the IPF default, -AA. That way you'll work with all of the other ISVs that use the default.

>application crashed during initialization of the 3rd p.l.

This is unexpected.

>we had the 3rd p.l relinked with -Bsymbolic and it works fine now.

This shouldn't have fixed anything if the only issue was -AA vs -AP.

>how can I ensure from my side that the application will work?

You need to figure out the real cause why your application aborted. Not just throw a dangerous option like -Bsymbolic at it.
And of course, port it to -AA.

[Krishna R]

Thanks for the info.

I understand what you are saying, but I need to debug more and find the root cause.
(btw, we are currently changing to use -AA)

Thanks again for the help. I will get back incase I find something/need more information.

[Dennis Handly]

>but I need to debug more and find the root cause.

Basically if -Bsymbolic fixes it, it would mean you have two classes or variables with the same name but different contents/layouts.

I have a tool that will find these things.

[Krishna R]

Can you please share the tool?

In our case, I think the conflict is between libstd and libstd_v2.

The crash has the following stack trace (and the problem was solved by using -Bsymbolic)

#8 0x40000000006883d0:0 in fatalSignalHandler ()
#9
#10 0xc0000000000ead20:0 in pthread_mutex_lock+0x400 ()
from /usr/lib/hpux64/libpthread.so.1
#11 0xc000000000357170:0 in __thread_mutex_lock+0xb0 ()
from /usr/lib/hpux64/libc.so.1
#12 0xc00000000161c530:0 in _HPMutexWrapper::lock(void*)+0x90 ()
from /usr/lib/hpux64/libstd_v2.so.1
#13 <<3rd party lib code>>


Lets say, I have 2 libraries (say, other than libstd) with objects of same name but different internals, how should I overcome this problem if I should not use -Bsymbolic?

[Dennis Handly]

>Can you please share the tool?

See show_remaining_imports_elf.sh attached.
You use the "-dup" option and specify your executable and any shlibs you dynamically load. The tool should figure out which you use but if not, just add them too.

>I think the conflict is between libstd and libstd_v2.

There are no conflicts there, since one is in namespace std.

>The crash has the following stack trace (and the problem was solved by using -Bsymbolic)

It shouldn't.

#9
#10 0xc0000000000ead20:0 in pthread_mutex_lock+0x400
libpthread.so.1
#11 0xc000000000357170:0 in __thread_mutex_lock libc.so.1
#12 0xc00000000161c530:0 in _HPMutexWrapper::lock libstd_v2.so.1
#13 <<3rd party lib code>>

Typically this occurs because that lib or some other lib wasn't compiled with -mt and libpthread is linked into the application.

>I have 2 libraries with objects of same name but different internals, how should I overcome this problem if I should not use -Bsymbolic?

You do it according to the Standard, you use lawyers. You put one into a copyrighted namespace and sue anyone that uses your namespace.

[Krishna R]

Gotcha :)

Thanks.