On Sun, 10 Jul 2011 16:48:16 +0200 Lionel Elie Mamane <lionel@mamane.lu> wrote: > (Please CC me on replies, as I'm quite behind on reading MLs. M-F-T > set accordingly.) From the bug report: > In the unusual case that your > package uses libltdl directly, it is still necessary to empty the > dependency_libs part of all .la files remaining in the package. i.e. there is no issue here. If you want to retain the .la file, just ensure that dependency_libs is cleared. libltdl uses a different field in the .la file which does not need to be touched. .la file removal is fine for most packages, those which need to retain the .la file must simply clear the dependency_libs field. Simple. > OK. What is slightly unclear to me, is that "being loaded by libltdl" > is a thing that is external to the package. The usual mechanism is as plugins for a specific library, so why would random third-party operations be directly using plugins which are part of a different library? If libfoo has plugins libfoo-magic and libfoo-super, those plugins would normally be only accessible via calls made via libfoo itself. bar -> dynamic linkage against libfoo bar uses a symbol exported by libfoo and knows nothing about plugins. libfoo uses the plugin to complete the action requested by bar libfoo processes the results of the plugin and serves that as the return value to bar. e.g. bar contains a call to: const char * getDatabaseName (fooConnection *c) libfoo implements this symbol by loading the "database" plugin. The plugin sorts out the details. libfoo handles the plugin return value and then returns a string to bar In that scheme, bar has no need to know about the plugins. The .la file won't matter as long as libfoo has a way of finding it's own plugins. The .la file is not the only way of locating the plugin. Other methods which don't use libltdl do not necessarily need the .la file either. > If there is *one* program > anywhere (even not packaged in Debian or local to an enterprise) that > uses libltdl to load library foo, we break that program by removing > the .la file. I don't see a valid reason for a third-party program to try to directly load plugins which are part of a different library. > So I don't really understand why we (we=Debian) consider > it a good thing to remove the .la file, even if nothing in Debian, or > nothing we know of, uses libltdl to load that library. You are free to retain the .la file for any package - as long as the dependency_libs field is cleared. Why would some random library be expected to support being opened via a .la file instead of normal dynamic linkage? > > With MultiArch, you may still get problems here because those > > directories will be changing. If those paths are within the sole > > control of this package, fine - both parts can change at the same time. > > If you're relying on paths which come from a separate source package, > > it'll likely break. > > I suppose we'll have a controlled / synchronised migration for all > ODBC drivers? Or should each driver just unilaterally stick > $(dpkg-architecture -qDEB_HOST_MULTIARCH) somewhere in the path? > > I presume that > /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/odbc > is better than > /usr/lib/odbc/$(dpkg-architecture -qDEB_HOST_MULTIARCH) This is covered in the MultiArch docs but from my understanding, it would be: /usr/lib/arm-linux-gnueabi/odbc/ e.g. libgl1-mesa-dri: /usr/lib/x86_64-linux-gnu/dri -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpp2Ey8jCcvR.pgp
Description: PGP signature