What is the logic behind .so versus and .so.1. I’m building
an embedded image and it appears that some application
requires .so.1 and other .so.
- Mario
What is the logic behind .so versus and .so.1. I’m building
an embedded image and it appears that some application
requires .so.1 and other .so.
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
What is the logic behind .so versus and .so.1. I’m building
an embedded image and it appears that some application
requires .so.1 and other .so.
When you link against a library, you pass -lname, which looks
for libname.so then libname.a
So you want to have a libname.so for linking. This should be
a link to the latest version, eg libname.so.1
Now, the -soname=libname.so.1 that you passed to the link
line for making libname.so.1 inserts a SONAME record, which
when you link against libname.so creates a NEEDED entry
against libname.so.1
Now consider that you update to libname.so.2, and move the
link.
Your old apps will still try to load libname.so.1, but newly
linked apps will look for libname.so.2
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:98r6nb$jpq$1@nntp.qnx.com…
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
What is the logic behind .so versus and .so.1. I’m building
an embedded image and it appears that some application
requires .so.1 and other .so.When you link against a library, you pass -lname, which looks
for libname.so then libname.aSo you want to have a libname.so for linking. This should be
a link to the latest version, eg libname.so.1Now, the -soname=libname.so.1 that you passed to the link
line for making libname.so.1 inserts a SONAME record, which
when you link against libname.so creates a NEEDED entry
against libname.so.1Now consider that you update to libname.so.2, and move the
link.Your old apps will still try to load libname.so.1, but newly
linked apps will look for libname.so.2
That means I can get rid of .so link at runtime?
Your old apps will still try to load libname.so.1, but newly
linked apps will look for libname.so.2
That means I can get rid of .so link at runtime?
Yup.
But usually the .so.1 is linked to the .so file, right? Or I guess the
other way around; the .so.1 is the REAL file (version 1), and .so is linked
to the most current .so.X. I’m guessing …
Colin Burgess <cburgess@qnx.com> wrote in message
news:98rdu6$n7k$1@nntp.qnx.com…
Your old apps will still try to load libname.so.1, but newly
linked apps will look for libname.so.2
That means I can get rid of .so link at runtime?Yup.