Hi all,
Regarding my original question about backwards compatibility of binaries
(between DU 4.0 and 3.2) I received the following replies... As I really
suspected what I was proposing to try is not really a good idea, not
really supported and too risky to contemplate in a production environment!
Thanks to all for their replies...
Peter Greinig. <pjg_at_butlins.co.uk>
--------------------------------------------------------------------------
From: "Huehls, Mark R." <huehlsm_at_indy.navy.mil>
Not with Ingres, but with Oracle. We had to recompile, when switching
between 3.2c and 4.0b with the application we are developing. We are
using DEC C++ with embeded SQL, and Oracle.
--------------------------------------------------------------------------
From: Pat Lampert <lampert_at_decatl.alf.dec.com>
Digital UNIX is only upward compatible. Not downward. There is a
high likelyhood that your images produced on the 4.0 machine will
fail with a shared library mismatch when you try to run them on
3.2. Upgrade your production machines first.
--------------------------------------------------------------------------
From: Dave Courtade <drc_at_odo.amherst.com>
I'm sure you realize you'll need to static link and binaries. Once that's
out of the way... We have tried the same thing and found that pthreads is
not portable upward. Since we depend on that greatly, we haven't tried too
much to go around it. We're just going to try to keep a minimal amount of
system resource at 3.2 to support delivered systems and do new development
on 4.x.
The pthreads confuses me still, there is dynamic library support for a
different version of thraeding, but not for static. Oh well, I guess I'm
off your question now.
--------------------------------------------------------------------------
From: Richard Renshaw <rrens_at_hcia.com>
We did the same thng, and found out that yes, the binaries are compatible,
but there still are some problems. There have been some changes in the
library structure between 3.2 and 4.0 and if you compile a program under
4.0 that uses a library that does not exist in 3.2 you're going to have a
problem. Other that that (which only occured with one program) we didn't
have any problems moving executables from the dev machine to the production
one.
--------------------------------------------------------------------------
From: "Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>
In general, binaries produced on a V4.0x system won't work on a V3.x
system. You *might* get lucky, but in general things will fail. So
you are likely to not succeed if you try it. Things are guaranteed
to be forward compatible, at least the stuff we (Digital) provide; we
can't promise other vendors will be as careful to preserve the binary
compatibility we try to offer. So your V3.2x binaries should work on
a V4.0x system, although they might work better recompiled.
--------------------------------------------------------------------------
From: Dave Cherkus <cherkus_at_homerun.unimaster.com>
No. I've seen problems doing this. The /sbin/loader program reports
unresolved symbols, etc. In any case it's not a supported config.
--------------------------------------------------------------------------
Received on Fri Sep 12 1997 - 14:30:48 NZST