Please explain to me the rules how an application developed in Momentics (or
whoever) decides it requires for example, a libxxx.so.1 and not a libxxx.so.
My project consist of an application plus a number of dynamic libraries, all
developed in Momentics. When I build my libraries under Momentics I never
specify any release numbers (or do I?) and all that is present is libxxx.so
(and libxxx_g.so), but suddenly my applications (also built under Momentics)
wants libxxx.so.1. Of course libxxx.so.1 does not exist and either I have to
manually rename the lib or create a link. A bit annoying especially
debugging from a Windows platform via qconn.
Or am I missing something here?
Francois
Francois Joubert <francois@truvelo.co.za> wrote:
Please explain to me the rules how an application developed in Momentics (or
whoever) decides it requires for example, a libxxx.so.1 and not a libxxx.so.
When you go to link with -lfoo, qcc will by default look for libfoo.so and then
libfoo.a. Inside of the libfoo.so’s ELF header is a SONAME value (you can view
it with the output of “objdump -x libfoo.so | grep SONAME”). The linker will
use this SONAME, if found, for the required library rather then the filename.
This allows for versioning of shared libs, with the libfoo.so normally being
a symlink to the correct version for up-to-date development.
chris
\
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
So the answer is to leave the apps alone and create a bunch of symlinks
for all libs?
Evan Hillas <blarg@blarg.blarg> wrote:
So the answer is to leave the apps alone and create a bunch of symlinks
for all libs?
Not really. What should happen is this…
libfoo.so.1
libfoo.so.2
libfoo.so.2a
libfoo.so.3
libfoo.so → libfoo.so.3
…so the only symlink is to the one the tools use to link the app with.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop wrote:
Evan Hillas <> blarg@blarg.blarg> > wrote:
So the answer is to leave the apps alone and create a bunch of symlinks
for all libs?
Not really. What should happen is this…
libfoo.so.1
libfoo.so.2
libfoo.so.2a
libfoo.so.3
libfoo.so → libfoo.so.3
…so the only symlink is to the one the tools use to link the app with.
chris
That’s hardly a good solution for a small footprint. I would think the
following is better:
libfoo.so.3
libfoo.so → libfoo.so.3
libfoo.so.1 → libfoo.so.3
libfoo.so.2 → libfoo.so.3
libfoo.so.2a → libfoo.so.3
That’s hardly a good solution for a small footprint. I would think the
following is better:
libfoo.so.3
libfoo.so → libfoo.so.3
libfoo.so.1 → libfoo.so.3
libfoo.so.2 → libfoo.so.3
libfoo.so.2a → libfoo.so.3
The entire point of changing the solib number is so when you make binary
incompatible changes you don’t break apps. Your symlinks here will not
work since it defeats the whole point of having mulitple versions.
For example, libph.so.1, libph.so.2 and libph.so.3 are totally different
and you cannot just symlink all of them to one lib and hope that everything
will work. They won’t.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop wrote:
That’s hardly a good solution for a small footprint. I would think the
following is better:
libfoo.so.3
libfoo.so → libfoo.so.3
libfoo.so.1 → libfoo.so.3
libfoo.so.2 → libfoo.so.3
libfoo.so.2a → libfoo.so.3
The entire point of changing the solib number is so when you make binary
incompatible changes you don’t break apps. Your symlinks here will not
work since it defeats the whole point of having mulitple versions.
For example, libph.so.1, libph.so.2 and libph.so.3 are totally different
and you cannot just symlink all of them to one lib and hope that everything
will work. They won’t.
I now understand the reason for this: The Libs API can be subtracted
from and changed to do things differently as well as added to, therefore
the program looking for some feature in lib won’t find it in a later
version of the lib.
I would bet that most libs are only ever added to and that the only
changes are bug fixes, then the link-all-to-one method will work most of
the time.
I guess that sometimes a bug fix will cause a problem, in that case, to
reduce duplication every binary destined for the target would need
recompiled against the solib, right?
Cheers,
Evan
On Wed, 25 Aug 2004 09:24:35 +1200, Evan Hillas wrote:
Chris McKillop wrote:
I now understand the reason for this: The Libs API can be subtracted
from and changed to do things differently as well as added to, therefore
the program looking for some feature in lib won’t find it in a later
version of the lib.
I would bet that most libs are only ever added to and that the only
changes are bug fixes, then the link-all-to-one method will work most of
the time.
I guess that sometimes a bug fix will cause a problem, in that case, to
reduce duplication every binary destined for the target would need
recompiled against the solib, right?
Cheers,
Evan
Isn’t the “proper” answer just to use libtool? Isn’t it designed to handle
all this transparently?
Rob Rutherford
Isn’t the “proper” answer just to use libtool? Isn’t it designed to handle
all this transparently?
No, it is there to take care of figuring out how to BUILD the shlib/lib
on a given OS. Not how to use or deploy it.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
I now understand the reason for this: The Libs API can be subtracted
from and changed to do things differently as well as added to, therefore
the program looking for some feature in lib won’t find it in a later
version of the lib.
I would bet that most libs are only ever added to and that the only
changes are bug fixes, then the link-all-to-one method will work most of
the time.
It could work sometimes, but the specific case I mentioned it would not
(libph).
I guess that sometimes a bug fix will cause a problem, in that case, to
reduce duplication every binary destined for the target would need
recompiled against the solib, right?
No, not if you are carefull. We have made changes to libph.so.2
on 6.3.0 for old apps to work with the changes to Photon without
needing a recompile. If you have to recompile, generally you need to
make a new solib number.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop <cdm@qnx.com> wrote:
That’s hardly a good solution for a small footprint. I would think the
following is better:
libfoo.so.3
libfoo.so → libfoo.so.3
libfoo.so.1 → libfoo.so.3
libfoo.so.2 → libfoo.so.3
libfoo.so.2a → libfoo.so.3
CM > The entire point of changing the solib number is so when you make binary
CM > incompatible changes you don’t break apps. Your symlinks here will not
CM > work since it defeats the whole point of having mulitple versions.
CM > For example, libph.so.1, libph.so.2 and libph.so.3 are totally different
CM > and you cannot just symlink all of them to one lib and hope that everything
CM > will work. They won’t.
CM > chris
When an application is first created, unless the programmer takes steps
to specifically do otherwise, aren’t the *.so (as opposed to *.so.#)
versions usually referenced by the program?
In other words, if I purchased a Photon program from someone else, and
it works fine, and I subsequently upgrade to QNX V 6.4, isn’t there a good
chance that my purchased app won’t work anymore anyway because it refers
to libph.so and not libph.so.3?
Xiaodan Tang <xtang@qnx.com> wrote:
XT > Bill Caroselli <qtps@earthlink.net> wrote in message
When an application is first created, unless the programmer takes steps
to specifically do otherwise, aren’t the *.so (as opposed to *.so.#)
versions usually referenced by the program?
In other words, if I purchased a Photon program from someone else, and
it works fine, and I subsequently upgrade to QNX V 6.4, isn’t there a good
chance that my purchased app won’t work anymore anyway because it refers
to libph.so and not libph.so.3?
XT > I believe application will actually looking for libph.so.3 instead of
XT > libph.so,
XT > do a “objdump -x app” and check out the NEEDED line yourself.
XT > -xtang
As usual, you are correct. This begs the question
Who, if anyone, looks at the *.so (non *.so.#) version of a library?
Bill Caroselli <qtps@earthlink.net> wrote in message
news:cghvm4$hhh$1@inn.qnx.com…
Chris McKillop <> cdm@qnx.com> > wrote:
That’s hardly a good solution for a small footprint. I would think the
following is better:
libfoo.so.3
libfoo.so → libfoo.so.3
libfoo.so.1 → libfoo.so.3
libfoo.so.2 → libfoo.so.3
libfoo.so.2a → libfoo.so.3
CM > The entire point of changing the solib number is so when you make
binary
CM > incompatible changes you don’t break apps. Your symlinks here will
not
CM > work since it defeats the whole point of having mulitple versions.
CM > For example, libph.so.1, libph.so.2 and libph.so.3 are totally
different
CM > and you cannot just symlink all of them to one lib and hope that
everything
CM > will work. They won’t.
CM > chris
When an application is first created, unless the programmer takes steps
to specifically do otherwise, aren’t the *.so (as opposed to *.so.#)
versions usually referenced by the program?
In other words, if I purchased a Photon program from someone else, and
it works fine, and I subsequently upgrade to QNX V 6.4, isn’t there a good
chance that my purchased app won’t work anymore anyway because it refers
to libph.so and not libph.so.3?
I believe application will actually looking for libph.so.3 instead of
libph.so,
do a “objdump -x app” and check out the NEEDED line yourself.
-xtang
Bill Caroselli <qtps@earthlink.net> wrote:
As usual, you are correct. This begs the question
Who, if anyone, looks at the *.so (non *.so.#) version of a library?
The linker.
-seanb
Sean Boudreau <seanb@qnx.com> wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
As usual, you are correct. This begs the question
Who, if anyone, looks at the *.so (non *.so.#) version of a library?
The linker.
Which was actually my original answer to the original question. 
Around and around we go…
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/