Gabriel,
unfortunately you seem to insist on the "DLL Hell" as the problem.
Although my problem is connected with exe-dll-compatibility it is not
a problem of a shared dll. Now, as mentioned in a previous posting,
it is a feature of the brlcad.dll that it can be replaced with a more
recent version. BTW, you haven't to go to the registry to see its
version the dll's properties dialog will show it.
However I see that Linux people have problems with this philosophy. I
personally like the Debian distributions because it is so easy to
install new programs with the package manager. But on the downside it
is very dangerous to use software from outside the distribution. The
distribution's maintainers don't care much about software they do not
compile by their self. If a library has changed they recompile all
programs depending on this library. All other programs have bad luck.
I end up in being very dependent from the distribution's repository.
E.g I tried to run (and then to compile) a BRL-CAD 5.x with a current
Linux distribution. I had to set up an old RH to get this working.
Now, think of the lucky situation that you could update a program by
upgrading a dll as on Windows. You won't believe that this always
works ("search for "DLL Hell"") and I had to admit you are right. The
dynamical linker (Windows or Linux doesn't matter) will take care of
the APIs to be compatible. But if this fails or you get problems
because of behavior changes in the dll you are in trouble. Hence we
could think of a mechanism which allows the executable to compare the
dll version number with a stored one (see e.g. "Version Numbering" in
http://en.wikipedia.org/wiki/Dependency_hell#Solutions for an idea on
how to handle this) and maybe warn the user about a probable
incompatible library.
Regards,
Daniel
2010/1/29 Gabriel M. Beddingfield <[email protected]>:
>
>
> On Fri, 29 Jan 2010, Daniel Roßberg wrote:
>
>>>> many programs using these. And there is my point: The programs
>>>> memorized the Python, TCL, etc. library version they were build with.
>
> [snip]
>>>
>>> Not exactly. When they load the .so-file (equiv. of a DLL) there is one
>>> or
>>> more API versions (integer) encoded in the library file. ld looks for a
>
> [snip]
>>>
>>> So, they don't look into a manifest file, it's encoded in the so-file.
>>
>> We have probable a misunderstanding here. In the mentioned paragraph
>> I wasn't talking about source and object files but about executable
>> and .deb files. I.e. if I install a .deb file all its dependencies
>> are mentioned in this file without access to the .so files.
>
> Possibly! :-) Windows is such a pain.
>
> In Linux, this sort of dependency is tracked both in packaging and at
> run-time. So, it's possible to have 4 or 5 different versions of librt
> installed... and it always "does the right thing." Still, the way libtool
> works is fundamental to the way that packaging is done (including .deb
> packages).
>
> But searching for "DLL Hell" is still a good direction. I think the common
> solution is to have a registry key and GUID that your package can look up at
> install-time to see if you have a compatable version of another piece of
> software.
>
> For example, I have a program on windows using the MSI packager with a
> "Product" GUID of {6101CFDF-9885-4084-B953-7DDF67232182}. You can look up
> in the registry:
>
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{6101CFDF-9885-4084-B953-7DDF67232182}\DisplayVersion
>
> And see that 1.0.7 is installed. There's also a Major/Minor version number
> you can query. So, you can set up your installer to query things about the
> installation properties of another piece of software like this.
>
> But that's the extent (or beyond the extent) of my knowlege in Windows
> library dependency management. :-)
>
>> However, you made an interesting point there: "ld looks for a library
>> with the right ... internal API version to load." Where does ld know
>> "the right internal API version" from? (I hope the answer isn't
>> "libtool". BTW, "man libtool" gives a rather short explanation.)
>
> It's part of the format of the .so files. See:
>
> http://www.gnu.org/software/libtool/manual/
>
> -gabriel
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
