dyncall_external ???

[Grigoriy Shcherbyak]

Hello!

I have my application cored and can not understand what is happening. Used two approaches when built application

1:
cc -w -DHAVE_CONFIG_H -I. -I. -I../.. -I/nfs/home/gshcherb/replay/include -I/nfs/home/gshcherb/replay/general/include -g -c tester.c

cc -w -g -o tester tester.o -L/usr/contrib/X11R6/lib -lXm -lXp -lXt -lXmu -lSM -lICE -lX11 -lm

Works fine.

2. (just changed to link against static libXt)
cc -w -g -o tester tester.o -L/usr/contrib/X11R6/lib -lXm -lXp /usr/lib/libXt.a -lXmu -lSM -lICE -lX11 -lm

bring core file.

Why is it happening? On Solaris 8 and Linux system, I have no such issue.

bt:

rogram received signal SIGBUS, Bus error.
0x7abbf1a8 in $$dyncall_external+0 () from /usr/lib/libXm.4
(gdb) bt
#0 0x7abbf1a8 in $$dyncall_external+0 () from /usr/lib/libXm.4
#1 0x7acfe588 in _XmAddHashEntry+0x38 () from /usr/lib/libXm.4
#2 0x7acf6504 in XmeTraitSet+0x60 () from /usr/lib/libXm.4
#3 0x7acc81e4 in ClassPartInitialize+0x13c () from /usr/lib/libXm.4
#4 0x16a44 in CallClassPartInit+0x38 ()
#5 0x16b90 in XtInitializeWidgetClass+0x130 ()
#6 0x16b74 in XtInitializeWidgetClass+0x114 ()
#7 0x177a0 in _XtCreateWidget+0x68 ()
#8 0x17b84 in XtCreateManagedWidget+0xb0 ()
#9 0x11c14 in main (argc=1, argv=0x7f7f0524) at tester.c:647


Thanks.

[Peter Nikitka]

Hi,

your way of linking the executable with an archive version of a library has to be done this way:

cc -w -g -o tester tester.o -L/usr/contrib/X11R6/lib -lXm -lXp -Wl,-a,archive -lXt -Wl,-a,default -lXmu -lSM -lICE -lX11 -lm

On Solaris you should change to a corresponding pendant - your version is not portable when using modern compilers, IMHO.

mfG Peter

[Dennis Handly]

You are getting an abort because the plabel you are calling is most likely 0.

Why would you want to link against an evil archive lib? You should be consistent and not mix and match shared vs archive system libs.

Also in general you should never use -w. Instead you should use +W### to suppress specific warning messages.

>Peter: your way of linking the executable with an archive version of a library has to be done this way:

There is no real difference between .../libXt.a, your -Wl,-a and using -l:libXt.a
I doubt this will change Grigoriy's abort.

>not portable when using modern compilers,

This has nothing to do with compilers. This is all linker magic.

[Grigoriy Shcherbyak]

Thanks for the suggestions.

Peter, unfortunately you way do not prevent issue appearing.

Dennis, i have to link against one static library and several shared libraries by project requirements. I have found that when I link statis libXt and static libXm to my application everything works fine, but if one of these libraries linked as static and another as shared then I have the issue.

What do you mean about plabel=0. Does it means that on some stage dynamic loader do not know where it should invoke function from and trying to look up this function and get failure? Or just something close to this description.

Why, why, why static libraries are evil???

Thanks for you replies - I have no other sources to get any information about this. If there is some e-book that describe all this magic for HP and you can point me it would be perfect.

[Dennis Handly]

>I have to link against one static library and several shared libraries by project requirements.

Just don't link with libXt.a.

>I have found that when I link archive libXt and archive libXm to my application everything works fine, but if one of these libraries linked as static and another as shared then I have the issue.

This is explicitly mentioned by the linker as something you shouldn't do.

>What do you mean about plabel=0.

There is a variable that is a pointer to a function (plabel). If 0, it wasn't initialized yet.

>why static libraries are evil???

Archive libs are evil because they don't automatically change when shared libs are patched. If mixing archive and shared, you can get combinations that no longer work together.

>If there is some e-book that describe all this magic for HP

http://docs.hp.com/en/B2355-91015/linkhelp.html

And the caution:
http://docs.hp.com/en/B2355-91015/creatingandusinglibraries.htm#MIXINGSHAREDANDARCHIVELIBS

[Peter Nikitka]

Hi,

a nearly obvious thing you should check:
Are there any patches, which should be applied to update the archive version of these libraries? Perhaps the shared versions are part of more recent (different) patches?

mfG Peter