Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i) - HP UX

This is a discussion on Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i) - HP UX ; We have an C++ application server that runs on Windows and several different Unix platforms. It's a rewrite and upgrade of an old strictly C program. For some of the crossplatform parts we use ACE 5.4 We now use gcc ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i)

  1. Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i)

    We have an C++ application server that runs on Windows and several
    different Unix platforms. It's a rewrite and upgrade of an old strictly
    C program.
    For some of the crossplatform parts we use ACE 5.4

    We now use gcc 3.4.2
    I'm striking a problem in that a dynamically linked binary built on our
    HPUX10 server will immediately die with core dump on a clients
    HPUX11.11 server (with no dev tools). Their server uses dynamic
    libraries sourced from hp's testdrive machines. The coredump occurs
    somewhere in libstdc++.
    If I upload our program to the testdrive 11i server, it runs, but will
    hang. Very simple helloworld programs work fine.

    I'm currently waiting for the client to run some helloworld apps
    compiled on HPUX10 but linked with various options, in the hope that
    will narrow down the symptoms.

    I'm open to any suggestions.

    Thanks in Advance,
    Lance


  2. Re: Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i)

    I didn't make myself very clear. I have their coredump " Their server
    uses dynamic
    libraries sourced from hp's testdrive machines. The coredump occurs
    somewhere in libstdc++. " I can't tell exactly where as the stack and
    symbols information for the stacktrace isn't available?

    I have tried static linking to various degrees, it still dumps core.
    I get an interesting message from gdb when I try to view their core
    dumps "shared libraries privately mapped", I haven't managed to find
    anything relevant on google regarding that, perhaps it means something
    to others?
    Thanks,
    lance


  3. Re: Problems running programs built and linked with GCC/ HPUX10 onHPUX11.11 (11i)

    On 8 Jun 2005 16:50:56 -0700
    lancep@ams.co.nz wrote:

    > I didn't make myself very clear. I have their coredump " Their server
    > uses dynamic
    > libraries sourced from hp's testdrive machines. The coredump occurs
    > somewhere in libstdc++. " I can't tell exactly where as the stack and
    > symbols information for the stacktrace isn't available?


    Trying to get C++ programs to work with different versions of the
    library is not easy. Can you download the same libraries and link
    against them? If not, I suggest sending your user your libstdc++
    instead of this unknown (to you) library.

    > I have tried static linking to various degrees, it still dumps core.


    Then you should be able to get a traceback, as long as you statically
    linked libstdc++.

    > I get an interesting message from gdb when I try to view their core
    > dumps "shared libraries privately mapped", I haven't managed to find
    > anything relevant on google regarding that, perhaps it means something
    > to others?


    AFAIK, it means that they are mapped in the private address space of
    the process, and hence can be breakpointed. This has to do with the
    memory layout of PA-RISC systems.

    Can't you get hold of a development environment that matches your
    customer's production environment a bit more closely? There have
    been quite a few changes from HPUX 10 to 11.11, and especially when
    you're using C++ (why? if it's a straight port of an old 'C' program
    there's little gain from pulling in C++, only lots of grief) a close
    match between the libraries is important.

    Take care,

    --
    Stefaan
    --
    As complexity rises, precise statements lose meaning,
    and meaningful statements lose precision. -- Lotfi Zadeh

  4. Re: Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i)

    Hi Stefaan, thanks for your assistance.
    It seems i've made a couple of important typos in my message (yay for
    winter cold brain-fog).
    We're developing on 11.00 not 10. The message from gdb (which has a
    problem where it doesn't unmangle c++ names in stacks - any ideas on
    that? )

    The program is not a port, it's a significant rewrite and upgrade in
    C++. Apparently we're stuck on 11.00 until all the customers machines
    move to 11i.


    I get names for the library functions now, not sure whether that's due
    to linking differently or a newer version of gdb.
    stack from coredump for a simple program, statically linked, that
    performs an opend and prints the result using std::cout
    "Core was generated by `opend-no-st'.
    Program terminated with signal 11, Segmentation fault.
    Unknown si_code. Report to HP.
    #0 0x3b47c in _ZNSo6sentryC1ERSo+0x1c ()
    (gdb) ba
    #0 0x3b47c in _ZNSo6sentryC1ERSo+0x1c ()
    #1 0x3b6c0 in
    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES 5_PKc+0xd0 ()
    #2 0x16024 in main+0x4c ()
    (gdb) li
    1 ./libgcc2.c: No such file or directory.
    in ./libgcc2.c
    (gdb) up
    #1 0x3b6c0 in
    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES 5_PKc+0xd0 ()
    (gdb) li
    1 in ./libgcc2.c
    "
    bash-2.04$ ldd opend-no-st
    /usr/lib/libdld.2 => /usr/lib/libdld.2
    /usr/lib/libc.2 => /usr/lib/libc.2
    /usr/lib/libdld.2 => /usr/lib/libdld.2


    Testdrive:
    HP-UX spe192 B.11.11 U 9000/800 1839940656 unlimited-user license
    Customer's test:
    HP-UX k360 B.11.00 U 9000/800 1099651301 unlimited-user license
    Customer's prod:
    HP-UX usatca01 B.11.11 U 9000/800 2653686204 unlimited-user license
    Our dev:
    HP-UX l1000 B.11.00 U 9000/800 535716577 unlimited-user license


  5. Re: Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i)


    > We're developing on 11.00 not 10. The message from gdb (which has a
    > problem where it doesn't unmangle c++ names in stacks - any ideas on that? )


    Well, that makes it appear that your customer gave you
    a corefile from an Itanium process, not from the PA-RISC 11.0
    and 11i systems you're trying to use to diagnose the problem.
    That can be seen from the fact that the C++ mangling systems
    are different on PA-RISC than on Itanium. The names in your
    stack traceback are from Itanium, so it's no surprise that
    a PA-RISC gdb can't demangle them.

    > "Core was generated by `opend-no-st'.
    > Program terminated with signal 11, Segmentation fault.
    > Unknown si_code. Report to HP.
    > #0 0x3b47c in _ZNSo6sentryC1ERSo+0x1c ()
    > (gdb) ba
    > #0 0x3b47c in _ZNSo6sentryC1ERSo+0x1c ()
    > #1 0x3b6c0 in
    > _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES 5_PKc+0xd0 ()
    > #2 0x16024 in main+0x4c ()


    These names do not demangle on PA-RISC systems :

    13: echo _ZNSo6sentryC1ERSo | c++filt
    _ZNSo6sentryC1ERSo
    14: echo _ZStlsISt11char_traitsIcEERSt1 | c++filt
    _ZStlsISt11char_traitsIcEERSt1
    15: echo _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES 5_PKc |
    c++filt
    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES 5_PKc
    16:uname -a
    HP-UX spider B.11.11 U 9000/898 1660693381 unlimited-user license
    17:

    But they do demangle on an Itanium system :

    10: echo _ZNSo6sentryC1ERSo | c++filt
    std:stream::sentry::sentry(std:stream&)(complete)
    11: echo _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES 5_PKc |
    c++filt
    std::basic_ostream >&
    std:perator<<
    >(std::basic_ostream >&,char const*)

    12: uname -a
    HP-UX wasp B.11.23 U ia64 2499385867 unlimited-user license
    13:

    (Sorry about the line-wrap there.)

    Anyway, that explains why you're having problems using these PA-RISC
    systems to diagnose an Itanium corefile :

    > Testdrive:
    > HP-UX spe192 B.11.11 U 9000/800 1839940656 unlimited-user license
    > Customer's test:
    > HP-UX k360 B.11.00 U 9000/800 1099651301 unlimited-user license
    > Customer's prod:
    > HP-UX usatca01 B.11.11 U 9000/800 2653686204 unlimited-user license
    > Our dev:
    > HP-UX l1000 B.11.00 U 9000/800 535716577 unlimited-user license


    Those are all PA-RISC machines (Itanium machines started with HP-UX
    11.20 or later).

    - Carl Burch
    HP WDB Team


  6. Re: Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i)

    : > We're developing on 11.00 not 10. The message from gdb (which has a
    : > problem where it doesn't unmangle c++ names in stacks - any ideas on that?)

    Because HP's gdb mainly supports aC++ and not g++.

    : Well, that makes it appear that your customer gave you
    : a corefile from an Itanium process, not from the PA-RISC 11.0 ...
    : That can be seen from the fact that the C++ mangling systems
    : are different on PA-RISC than on Itanium. The names in your
    : stack traceback are from Itanium, so it's no surprise that
    : a PA-RISC gdb can't demangle them.

    The latest g++ mangling for PA is the same as the IA-64 C++ ABI.

    : These names do not demangle on PA-RISC systems:

    They do, if you have the right c++filt.

    : But they do demangle on an Itanium system:

    Right.

    : Anyway, that explains why you're having problems using these PA-RISC
    : systems to diagnose an Itanium corefile:
    : - Carl Burch

    A simple file(1) would tell you if you had that problem.

  7. Re: Problems running programs built and linked with GCC/ HPUX10 on HPUX11.11 (11i)

    lancep@ams.co.nz wrote:
    > I'm striking a problem in that a dynamically linked binary built on
    > our HPUX10 server will immediately die with core dump on a clients
    > HPUX11.11 server (with no dev tools). Their server uses dynamic
    > libraries sourced from hp's testdrive machines.


    Can you expand on that "Their server uses dynamic libraries sourced
    from hp's testdrive machines?" On the surface it sounds like the
    client is using the HP testdrive program as a way to do full-time
    development rather than "kicking the tires."

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread