From: Trevor D. (Twylite) <tw...@cr...> - 2012-11-22 23:09:57
|
Hi, On 2012/11/22 06:49 PM, Porter, Don wrote: > Those are all ok as "things to try" but none of them are robust, "always > correct" answers like using the compiled in path value can be (so long > as the builder/installer team don't conspire to lie, and so long as clever > sysadmins don't relocate the non-relocatable.) In detail.... As I've pointed out, the default install location on Windows XP, Windows 7, and non-English Windows 7 can differ, and you cannot guarantee that the System Drive is C:. So there's no point in arguing "so long as ..." -- it simply cannot be that way in the Windows world. > 1) relative to libtcl.so - is impossible because Unix simply offers no way > to find out where the shared library that got linked into the running > program came from on the file system. This defect of unix is the key > cause of this strife. I haven't worked extensively in this area, but isn't that what dladdr() is supposed to do? It's been available on Linux, FreeBSD and OS/X for some time, and I see forum references to availability on Solaris as far back as 2002. > On unix, when you do not ignore embedders, the compiled in path values > truly are the only reliable foundation available to join together separately > installed binary parts and script parts. If I understand correctly you're describing a situation where a developer creates a binary B that links against tcl.so (provided by the Tcl package and in a standard library location) and also against ext.so (provided by the developer and could be installed somewhere else entirely, so long as the dynamic linker can locate it). ext.so is dynamically linked to B, but not dynamically loaded via pkgIndex + load + dlopen(). So the problem is: how does ext.so locate it's libraries? Unless dladdr() does what I think it does, code in ext.so doesn't know where ext.so lives to it can't attempt to look in the filesystem relative to ext.so. Which leaves two options: impose a rule requiring the libs to be installed relative to the Tcl installation (doesn't really make sense for a distinct application B); or hard-code the library path at build time. Distributing an application in such a manner would be abnormal in the Windows world. It is unusual to attempt to share the installed libraries of another application (in this case B attempts to share Tcl's libraries), and Windows DLL search order doesn't even support doing so unless the dependencies are installed in a system directory (not something Windows developers tend to do because of DLL Hell). Normally the application and all dependencies are bundled together in one install, with no external dependencies other than the OS. > Perhaps the Tcl 9 solution is to define the problem out of existence by > ending support for such install schemes. Instead, put in place the machinery > needed to attach script content directly to binary content in a way that > exposes to scripts as a virtual filesystem. AIUI, the concept has been proven > with "basekits" (if I have the term right). If all parts come from one file, > then we just no longer need [tcl_findLibrary] and all arguments over how > it ought properly function can go away. I don't actually see how that helps? An ext.so still wouldn't be able to find itself to mount its VFS. Alternatively you're imposing restrictions that would solve the existing problem but which you have previously dismissed? >> Which is why the only sane approach for a Windows developer (who >> distributes Tcl runtimes outside of a controlled environment) is to >> mangle the pkgconfig paths to be unusable, and ensure that the fall back >> logic is always used. Then everything works reliably. > Ok, what I"m hearing is that the order of the search path constructed > by tcl_findLibrary would be improved if it were platform-dependent. That may be the most sane approach. Clearly I have missed some of the subtleties of the *nix situation which seem to justify the pkgconfig approach, but it really doesn't work for Windows (where we can determine the DLL's file name if required). Regards, Twylite |