Hi all, I have been asked to summarize all the answers to the
dynamic linking question I previously asked. I will start
with what the original problem was, what our solution is,
and then list all thesummarize bits from the emails I received.
Original problem: Dynamic linking remembers the actual library
name with version numbers, even though executable was linked
without the version names. This means the exact library
name must be available on the target machine (or statically
linked).
E.g. Under Solaris 2.3, using -lXm while linking resolved to
/usr/lib/libXm.so which was a link to an ICS library named
libXm.so.2.3. The executable looks for libXm.so.2.3 at
run time.
Under Solaris 2.4, with Sun's Motif installed -lXm resolves
to libXm.so.3.
Our solution: Require customers have at least Solaris 2.4. Some
of the reasons are as follows:
i) Sun when providing a new version of their OS provides the
old libraries so old executables should still run.
ii) Sun's libraries are part of the OS and all the
customer has to do is install them.
iii) No licensing issues for Motif libraries (can even supply
mwm if we want!)
iv) Support is made simpler by using Sun libraries from the
start.
v) ICS libraries would have caused licensing issues.
Luckily we can do this as we have not yet supplied our
application to any customers so we do not have a customer
base on the Sun platform yet.
Summary of email information
============================
In general it is possible to run an executable built under Solaris
2.3 under Solaris 2.4 as long as all the libraries exist. Actually
getting your application to find these is a result of either
LD_LIBRARY_PATH at run time or -R option at link time (or both).
Other various information has been extracted from emails and listed
below.
---------------
From: Bart.Smaalders@eng.sun.com (Bart Smaalders)
If it can find compatible libraries, your 2.3 app will run on 2.4.
The other direction is less certain, since you may use features not
part of 2.3. This will be fixed in 2.6, where you'll know which
previous releases you will run on.
To fix the SONEEDED problem, try the following for your release build:
1) create a dummy library
% cat > foo.c
foo() {}
% cc -Kpic -c foo.c
% cc -G -h libXm.so -o libXm.so foo.o
2) Now link your (already debugged and working) app against this
dummy library instead of Mo'grief (:-)). Use the -z nodefs to
ignore complaints about all the symbols it can't find:
% cc -o myapp -z nodefs -R/usr/dt/lib:/usr/openwin/lib -L. -L/usr/openwin/lib ... -lXm ...
You may need to stick some data symbols into your dummy Motif lib
if you get errors here....
This app should now startup with any motif lib installed on the system.
Whether or not it works is another matter, of course; not all motifs are
binary compatible with each other (sigh).
---------------
From: Doug.Royer@eng.sun.com (Doug Royer [KD6HBW])
I think the problem here is hat /opt/ISC/... is a 3rd party
Motif (Sun did not have Motif then). I am not sure of how
you can solve this. The linker saves the library version
number in libs and binary programs so that binary compatibility
can take place. When Solaris 2.4 released with Motif there
were many 3rd party libaries and no *one* binary compatable
with the other. You may have to re-link :-(
---------------
From: guy@netapp.com (Guy Harris)
Unfortunately, the Motif libraries do *NOT* come as a standard part of
Solaris 2.3; you've picked up...
>Under Solaris 2.3:
>
>i) We are linking with the -lXm statement.
>ii) This resolves to /lib/libXm.so which is a link to
> /lib/libXm.so.2.3 which in turn is a link to
> /opt/ICS/motif/usr/lib/libXm.so.2.3.
...the ICS version of the Motif library for your Solaris 2.3 system,
but...
>Now under Solaris 2.4:
>
>i) We are linking with -lXm statement.
>ii) This resolves to /usr/dt/libXm.so which is a link
> to /usr/dt/libXm.so.3
...are using the Motif library that is packaged (to some extent) with
Solaris 2.4.
This may mean, unfortunately, that you're screwed in this particular
case. The one bit of good news is that if you build the binary under
Solaris 2.4, it'll *probably* work under Solaris 2.5, as 2.5 should also
include the Motif shared library, and will probably stick it in
"/usr/dt" (as it's included because Sun's signed up to the Motif-based
CDE, and "/usr/dt" is, I think, where CDE stuff is put).
Furthermore, the major version numbers of the two shared Motif libraries
are different; this may just be because ICS and Sun picked different
major version numbers for no particularly good reason, but it may also
be because the two shared libraries do *not* share a binary interface,
such that a program linked with one library may fail when run with the
other *even if you stick symlinks in to make it work*.
You may want to consider either:
1) *statically* linking with the Motif library, at least for
Solaris 2.3;
or
2) releasing separate Solaris 2.3 and Solaris-2.4-and-later
executables.
Note that the Solaris 2.3 dynamically-linked executable will work only
if somebody's actually bought Motif for their Solaris 2.3 system, unless
you buy the rights to ship the Motif dynamic library with your
executable - but what happens if they've already bought somebody
*else's* Motif package? Will they have to install both versions of the
shared library? What happens if they collide?
Statically linking the Solaris 2.3 executable with the Motif library
would handle that case as well.
The Solaris 2.4-and-later executable, if dynamically linked with the
Motif library, will require that the customer install whatever Solaris
2.4 package includes the Motif library, and that they install the
relevant Solaris 2.5-and-later packages to get the CDE stuff.
Note also that GCC is, as of when I last checked, too stupid to
understand that one might want to statically link with some libraries
but dynamically link with others, so you might have problems building
the application with GCC. (The problem isn't with the compiler proper;
it's with the "gcc" command, which is the "driver" program that runs the
various passes of the compiler, the assembler, and the linker.)
----------------
From: morgan.herrington@nosun.west.sun.com (Morgan Herrington)
The version number is only supposed to change when interfaces
in the library change, so in general you would NOT want to
link against the other version. I also *think* that Sun's
plan is to release both the old and the new version when
a new version comes out, in order to facilitate exactly the
compatibility that you discuss. [In particular, when the
next version of Motif is available, I *think* that Sun will
supply both a libXm.so.3 and a libXm.so.4]
I'm no authority, but I might venture a guess that the reason
that libXm.so.2 wasn't supplied in /usr/dt/lib is that Sun
did NOT ever include libXm.so in a Solaris release prior to
2.4. It was only released as part of the unbundled Software
Developer's Kit. It might even have had something to do
with the licensing arrangement Sun has for Motif. I'm just
speculating.
Anyway, I think you can *force* the behavior you're looking
for by using the "-h" option to "ld" (see the man page). You
should keep in mind that this is NOT guaranteed to work across
version changes in the library (and in fact, at least one
library interface is guaranteed to change [and presumably
break your code]).
------------------
Thanks to all for their input, it helped alot.
----------------------------------------------------------------
Tony Wise NETRIX Corporation
13595 Dulles Technology Drive
Internet : aew@netrix.com Herndon VA 22071
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:31 CDT