Hi,
Could you tell me why the dlls are usually not versioned unlike shared libs.
Isn’t it possible to have a process which loads a cam-cdrom.so.1.0 and
another one which loads a cam-cdrom.so.1.2?
Thanks,
Alain.
alain.bonnefoy@icbt.com sed in <3F965752.60103@icbt.com>:
Isn’t it possible to have a process which loads a cam-cdrom.so.1.0 and
another one which loads a cam-cdrom.so.1.2?
You can if you want to.
Just pass the appropriate filename to dlopen().
Version completion & searching isn’t automatic.
(It isn’t automatic even on explicit linking by -l)
kabe
kabe@sra-tohoku.co.jp a écrit:
alain.bonnefoy@icbt.com > sed in <> 3F965752.60103@icbt.com> >:
Isn’t it possible to have a process which loads a cam-cdrom.so.1.0 and
another one which loads a cam-cdrom.so.1.2?
You can if you want to.
Just pass the appropriate filename to dlopen().
Well, I’m still wonder why version is usually not used for dll!
Version completion & searching isn’t automatic.
(It isn’t automatic even on explicit linking by -l)
Maybe I don’t really understand what you mean but I’m afraid you are wrong:
If you have built a shared lib with SO_VERSION=1.0 in your commonk.mk,
your SO_NAME will be libmine.so.1.0 (objdump -p libmine.so)
So, in your /usr/lib, install it as libmine.so.1.0 and create a link
libmine.so → libmine.so.1.0.
if you build an executable with -lmine, at running time, it will load
libmine.so.1.0 even if there is another libmine.so.x.y (and even if we
remove the libmine.so link of course because the link is only usefull
for gcc).
regards,
Alain.
alain.bonnefoy@icbt.com sed in <3F96B482.9090305@icbt.com>:
Version completion & searching isn’t automatic.
(It isn’t automatic even on explicit linking by -l)Maybe I don’t really understand what you mean but I’m afraid you are wrong:
If you have built a shared lib with SO_VERSION=1.0 in your commonk.mk,
your SO_NAME will be libmine.so.1.0 (objdump -p libmine.so)
So, in your /usr/lib, install it as libmine.so.1.0 and create a link
libmine.so → libmine.so.1.0.
if you build an executable with -lmine, at running time, it will load
libmine.so.1.0 even if there is another libmine.so.x.y (and even if we
remove the libmine.so link of course because the link is only usefull
for gcc).
Well definition of the “automatic” varies, but
IIRC things like autoloading so.1.20 when the binary requires so.1
had been only implemented on SunOS4.
You’re talking about that
- build linker picks up SONAME from .so (which is → .so.1.0),
- embeds SONAME=.so.1.0 as NEEDED in the executable
- and so the runtime linker picks up .so.1.0,
which is absolutely right,
but there’s nothing dynamically determined here.
Anyhow you have to prepare .so → .so.1.0 symlink by yourself.
SONAME is just a string for the players, so you can put unrelated
library name here to play weird games too.
(Some linkers may implement trying .so.1.20 - .so.1.0 - .so.1 - .so
which can be called version completion, but that could be more of nuisance
nowadays)
You have to implement all these details when using dlopen()
explicitly, which may be the reason dlls doesn’t have version numbers.
Pros: easy to implement, easy to update the dll
Cons: multiple versions of dll with the same name not allowed
kabe
Ok Kabe,
In fact we can say there is no precise reason to decide to include or
not version number in dll names.
Maybe the problem reside in the fact that a shared libs linked at build
time (I think) when dlls are linked at execution time no?
That could cause some problems if the exe cannot find the correct lib
version (if we consider that the shared lib name is .so only) which is
maybe not the same thing with dll. right?
Alain.
kabe@sra-tohoku.co.jp a écrit:
alain.bonnefoy@icbt.com > sed in <> 3F96B482.9090305@icbt.com> >:
Version completion & searching isn’t automatic.
(It isn’t automatic even on explicit linking by -l)
Maybe I don’t really understand what you mean but I’m afraid you are wrong:If you have built a shared lib with SO_VERSION=1.0 in your commonk.mk,
your SO_NAME will be libmine.so.1.0 (objdump -p libmine.so)
So, in your /usr/lib, install it as libmine.so.1.0 and create a link
libmine.so → libmine.so.1.0.
if you build an executable with -lmine, at running time, it will load
libmine.so.1.0 even if there is another libmine.so.x.y (and even if we
remove the libmine.so link of course because the link is only usefull
for gcc).
Well definition of the “automatic” varies, but
IIRC things like autoloading so.1.20 when the binary requires so.1
had been only implemented on SunOS4.You’re talking about that
- build linker picks up SONAME from .so (which is → .so.1.0),
- embeds SONAME=.so.1.0 as NEEDED in the executable
- and so the runtime linker picks up .so.1.0,
which is absolutely right,
but there’s nothing dynamically determined here.
Anyhow you have to prepare .so → .so.1.0 symlink by yourself.SONAME is just a string for the players, so you can put unrelated
library name here to play weird games too.(Some linkers may implement trying .so.1.20 - .so.1.0 - .so.1 - .so
which can be called version completion, but that could be more of nuisance
nowadays)
You have to implement all these details when using dlopen()
explicitly, which may be the reason dlls doesn’t have version numbers.
Pros: easy to implement, easy to update the dll
Cons: multiple versions of dll with the same name not allowed
alain.bonnefoy@icbt.com sed in <3F98BDD4.5080609@icbt.com>:
Maybe the problem reside in the fact that a shared libs linked at build
time (I think) when dlls are linked at execution time no?
Partially correct.
Shared libraries are linked at build time AND runtime.
DLLs are explicitly loaded by calling dlopen() at runtime only.
(Thus you can’t know beforehand what DLLs the binary needs)
*Note to readers: “DLL” is a QNX term here which means a shared object
which isn’t linked by -l but only by explicit dlopen().
That could cause some problems if the exe cannot find the correct lib
version (if we consider that the shared lib name is .so only) which is
maybe not the same thing with dll. right?
The issue is same for both library and dll.
Version mismatch MAY cause problems for both of them.
If library version isn’t an issue, you can use a plain *.so library.
(Build linker would use the *.so filename as NEEDED if there’s no SONAME)
If dll version depends, you have to explicitly load
dlopen(“dll.so.1.0”, …), as ld.so module used for
shared library loading won’t play game here.
The “fact” that library uses version and dll doesn’t seems to be only
a historical fact; technically you can do it both ways.
(QNX libc has several versions, so libc.so needs to have version tho)
Someday the dll may switch to versioning scheme if version becomes a problem…
kabe
Ok,
Thanks a lot Kabe,
cheers,
Alain.
kabe@sra-tohoku.co.jp a écrit:
alain.bonnefoy@icbt.com > sed in <> 3F98BDD4.5080609@icbt.com> >:
Maybe the problem reside in the fact that a shared libs linked at build
time (I think) when dlls are linked at execution time no?
Partially correct.Shared libraries are linked at build time AND runtime.
DLLs are explicitly loaded by calling dlopen() at runtime only.
(Thus you can’t know beforehand what DLLs the binary needs)*Note to readers: “DLL” is a QNX term here which means a shared object
which isn’t linked by -l but only by explicit dlopen().
That could cause some problems if the exe cannot find the correct lib
version (if we consider that the shared lib name is .so only) which is
maybe not the same thing with dll. right?
The issue is same for both library and dll.
Version mismatch MAY cause problems for both of them.If library version isn’t an issue, you can use a plain *.so library.
(Build linker would use the *.so filename as NEEDED if there’s no SONAME)If dll version depends, you have to explicitly load
dlopen(“dll.so.1.0”, …), as ld.so module used for
shared library loading won’t play game here.The “fact” that library uses version and dll doesn’t seems to be only
a historical fact; technically you can do it both ways.
(QNX libc has several versions, so libc.so needs to have version tho)
Someday the dll may switch to versioning scheme if version becomes a problem…