linking current dynamic libraries .so vs .so.2
Martin the-Wos
I am linking the libDtWidget.so dynamic library. On the development
box this file symbolically links to libDtWidget.so -> libDtWidget.so.2
but on my test system the file link is libDtWidget.so ->
libDtWidget.so.1. When executed on the test sytem the program exits
complaining that it cant find libDtWidget.so.2.
So what to I need to send to my linker to cause to look at the
canonical file libDtWidget.so and not read in the actual so.# filname
that was used to create the dynamic library with the -h option.
TIA
Martin
mar...@att.net
Marc
One way to do this:
after linking your program, edit it (say, with vim) and replace the '.'
before the '2' by a \0 character (you can find one just after the '2' so
you just have to copy it, if you don't know how to type a null
character). If you really want to, you can do this to libDtWidget.so.2,
thus changing its SONAME, and you won't need to edit your program.
Now there is a good reason why there is a number at the end of the
library name, it means that the 2 libraries are not compatible (or that
the author did a mistake), so I do not think you should be doing what
you intend to do...
Dave Uhring
Upgrade the Solaris version on the test and production systems to the same
or later version used on the compile box.
Or downgrade the Solaris version used on the compile box.
Martin the-Wos
Well that worked on my dynamic libraries but then I ran into the fact
that I have a dynamic library libgen.so on my development system
(Solaris 8) but my test run system (Solaris2.6) only contains ONLY the
static libgen.a library.
Alrighty then- I need to upgrade the OS on the test system...
Thanks,
Martin
Marc
> Well that worked on my dynamic libraries but then I ran into the fact
> that I have a dynamic library libgen.so on my development system
> (Solaris 8) but my test run system (Solaris2.6) only contains ONLY the
> static libgen.a library.
You could always play with the -Bstatic -Bdynamic flags of the linker,
but...
> Alrighty then- I need to upgrade the OS on the test system...
... this is really your best choice.
Martin the-Wos
but the static libgen.a may be different between the OS versions. I
was originally hopping for a little independance form OS versions, but
it is best to be the same accross the board.
_Martin
Dave Uhring
> but the static libgen.a may be different between the OS versions. I
> was originally hopping for a little independance form OS versions, but
> it is best to be the same accross the board.
You can build your binaries on 2.6 and run them on 10, but not the other
way around.
Casper H.S. Dik
Linking libgen statically on S8 for use on S2.6 is not supported and
may not work; the reverse, however, is supported.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Jonathan Adams
>
> Well that worked on my dynamic libraries but then I ran into the fact
> that I have a dynamic library libgen.so on my development system
> (Solaris 8) but my test run system (Solaris2.6) only contains ONLY the
> static libgen.a library.
>
> Alrighty then- I need to upgrade the OS on the test system...
The general rule of thumb is compile on the earliest version of
Solaris you want your program to be able to run on.
Solaris generally offers binary backwards-compatibility (that is, a
dynamically linked binary compiled on SunOS 5.x which does not use
undocumented interfaces should work on SunOS 5.y, where y > x).[1]
Going the other way won't necessarily work.[2]
The "whacking your binary with a hex editor" approach is not a very
sound idea. =] (as an aside, linking statically (as another poster
suggested) to any of the system libraries (especially libc) is also
not a good idea -- patches can break you)
- jonathan
[1] This usually bi-directionally across maintainance updates of the
same release, as long as you aren't using new stuff.
[2] If it's going to fail, it will usually fail during ld.so's
initialization, as your program did. But don't press your luck.
Dragan Cvetkovic
> Solaris generally offers binary backwards-compatibility (that is, a
> dynamically linked binary compiled on SunOS 5.x which does not use
> undocumented interfaces should work on SunOS 5.y, where y > x).
Actually, it's y >= x :-)
Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!