Re: Run 10.20 App on 11.00 ?

From: David West (km4hr_at_netscape.net)
Date: 06/24/03 

Date: 24 Jun 2003 07:30:40 -0700

jholly@cup.hp.com (Jim Hollenback) wrote in message news:<3ef71bb1$1@usenet01.boi.hp.com>...
> David West (km4hr@netscape.net) wrote:
> : jholly@cup.hp.com (Jim Hollenback) wrote in message news:<3ef3e08c$1@usenet01.boi.hp.com>...
> : > Greg Cagle (gregc@gregcagle.com) wrote:
> : > : David West wrote:
>
> : > : > I have an app that runs on 10.20 but doesn't run on 11.00 and can't be
> : > : > upgraded. Is there any way at all to run this app on 11.00? Any sort
> : > : > of "compatibility mode" etc? Any way to use 10.20 libraries on 11.00
> : > : > or otherwise make the app think this is a 10.20 machine?
> : >
> : > Unless some one mucked with the install you should have 10.20 libraries
> : > on the 11.00 machiine. Look for libc.1 in /usr/lib. Compatibility is
> : > automagic.
> : >
> : > : What is the nature of the failure?
> : >
> : > Some more clues would help. I seem to remember that on 10.20 one could
> : > generate code for PA 2.0 architecture and 11.00 will run on a PA 1.1
> : > machine. Is it possible you have a PA 2.0 binary from 10.20 your trying
> : > to run on a PA 1.1 11.00 machine? this doesn't work.
>
> : This is an area that is a bit over my head but believe I can say with
> : confidence that the architecture of the 10.20 and 11.00 machines are
> : identical. They are both model B132 HPUX workstations. The program was
> : installed on both machines using the vendor's install scripts. The
> : install script relinks the binary.
>
> Bingo. You can't relink 10.20 objects on a 11.00 machine. You end up pulling
> the 11.00 libraries in and you core. The 10.20 libraries on the machine
> are there for already linked 10.20 binaries. It is not possible to build
> 10.20 applications on a 11.00 box. (well, not impossible, but very painful).
> Does this script use libc.a? This is a really big problem.
>
> : I don't recall any problems during
> : install. Now that I've said this perhaps I'll install again and pay
> : even closer attention. At any rate, a binary is created where there
> : wasn't one to begin with. We have also tried copying the binary from
> : the 10.20 machine to the 11.00 machine.
>
> Just about all well behaved 10.20 apps should run correctly on a 11.00 box.
> The area were you get into trouble is where you have a 10.20 app that is
> priviledge and it is mucking about in areas that are not portable. Also
> if the app links in libc.a then you basically up the creek because you have
> no way of fixing the problem. The app has pulled in api's that are not
> compatible with the 11.00 system. Archive libraries are nasty and bad.
>
>
> : We get the same identical
> : result on execution, as I recall. We experimented with pulling libc
> : from the 10.20 machine to the 11.00. I think the results were again
> : identical.
>
> I hope it was only libc.1 you moved. libc.2 is the libc for 11.00. This is
> probably not very productive since the libc.1 is probably very close on
> both machines.
>
> : I am an application programmer and usually don't get involved with
> : problems at this level but we have a consultant on site who is
> : primarily working on other projects. He is far more knowlegable on
> : these issues and is help me as time permits. He understands library
> : compatibility and such things far better than I. He feels that library
> : issues are the problem and has even suggested analyzing the "symbol
> : table" of the executable to see if there may be a way to create a
> : translation module to intercept the 10.20 library calls and translate
> : them to work with the 11.00 libraries.
>
> Again, you have the 10.20 libraries on the 11.00 system so this "translation
> module" is not needed. I still think your best approach is to get tusc
> and see where this thing crashes, or use gdb to examine the core file.
>
> : We are currently wondering if
> : there is a document describing what library calls changed between
> : 10.20 and 11.00.
>
> Its called the release notes.
>
> : This is really getting deep so if you have any ideas
> : that we might try please help.
>
> The best two suggestions is use tusc and/or gdb.
>
> : As you mentioned there is a /usr/lib/libc.1 on the 11.00 machine.
> : Should the app find this library automatically or is there something
> : you have to do to specifically instruct the app to use it?
>
> an app linked on a 10.20 machine will look for libc.1. You don't need
> to do anything because dld will load libc.1. You can verify this with chatr.
>
> : How would
> : the app know which library to use automatically?
>
> it is built in. Use chatr to see what the dependent libraries are.
>
> : I think my consultant
> : redirected a symbolic link to try and force the app to use this
> : library but I'm not sure exactly what he did. Is this library supposed
> : to be exactly the same as the one on 10.20?
>
> He should not be playing with the the libc.sl link. That is a really good
> way to break things. Besides, after the app is linked it doesn't use the
> link.
>
> : You said compatibility is
> : automagic but perhaps our crystal ball is busted.
>
> yes, especially if your crystal ball is archived.
>
> : If you can inject any insight into this issue it would be greatly
> : appreciated. I'll have my consultant help me translate your response.
>
> I would take a close look at the install script. If it is making use of
> libc.a your basically hosed at this point. You would then need to go back
> to source level and build from scratch. Archive libraries are nasty, ugly
> and insure you will have nothing but never ending problems. Don't use them.
>
> Good luck.

Problem solved!!

Thanks to all who responded to my post. Especially to you Jim. You
were hot on the trail of this turkey. It turned out that the vendor's
installation instructions recommend kernel parameter settings that are
insufficient. The problem with finding the solution was that that the
error indications were misleading. We were left chasing rabbits. But
we've stumbled onto some kernel parameter settings that work.

It is crucial that we keep this application going because without it
we'd have to get rid of HPUX. We like HPUX but the vendor only
supports Windows these days and they're pushing us to convert. We're
told by the vendor that they have almost no customer interest in Unix.
I suspect they like selling all the client licenses and upgrades for
every user PC and the enhanced support dependency, if the truth be
told. This makes HPUX an endangered species at this facility. It
frustrates me but there's nothing we can do but try to keep the system
going. We have in-house developed applications that rely on this app.
Our apps will have to be converted if/when we're eventually forced to
move to Windows. Hopefully we can make it another 5 years. I may be
retired by then if this keeps up. I have a certain disdain for
Windows. I hope Linux comes to the rescue. Anybody have any idea how
far into the future we might be able to continue upgrading this app as
we have to 11.00? Will this be the end?

If anyone is interested, the application is a programming interface to
an industrial control system made by Fisher Control Systems. We use it
to read pressures, temperatures, flows, etc from industrial processes.

Thanks again to all, especially Jim, for sharing your time and brain
cycles.

David

Relevant Pages

  • Re: Run 10.20 App on 11.00 ?
    ... installed on both machines using the vendor's install scripts. ... the 11.00 libraries in and you core. ... The area were you get into trouble is where you have a 10.20 app that is ... I would take a close look at the install script. ...
    (comp.sys.hp.hpux)
  • ldd/ldconfig problems with Fedora 2 x86_64
    ... to install a pre-compiled 3rd-party ... app is 32-bit and was compiled under RedHat Enterprise 3. ... installing Fedora 2 x86_64 installs many 32-bit libraries, ... as 'ldconfig /usr/lib', rebooted and reinstalled the vendor app. ...
    (comp.os.linux.misc)
  • Re: Three newbie questions!
    ... For example, say you install package foo.0.1, then one ... might have changed the way the app is spread throught the filesystem. ... depends on several libraries that you had to compile beforehand. ...
    (comp.os.linux.setup)
  • Re: Programming for different Word versions
    ... develop your app for the lowest version of Word ... Remove the reference to the Word library. ... or is it possible to install different word ... >> libraries on my development computer, ...
    (microsoft.public.word.vba.general)
  • Re: ClickOnce Nightmares
    ... your app need to install the settings. ... LAN) you could create a logon script that will automatically install the ... DownloadOptions options, ServerInformation& serverInformation) ... FileAccess access, Boolean asyncHint) ...
    (microsoft.public.dotnet.framework)