FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-10-2011, 02:48 PM
Lionel Elie Mamane
 
Default .la file removal, multiarch for plugins

(Please CC me on replies, as I'm quite behind on reading MLs. M-F-T
set accordingly.)

Taking this discussion out of bug#633256 and into debian-devel.

On Sat, Jul 09, 2011 at 11:13:47PM +0100, Neil Williams wrote:
> On Sat, 9 Jul 2011 23:06:03 +0200 Lionel Elie Mamane <lionel@mamane.lu> wrote:
>> On Sat, Jul 09, 2011 at 10:29:42AM +0100, codehelp@debian.org wrote:

>>> Package: sqliteodbc
>>> Usertags: la-file-removal

>>> To finish an old release goal from Squeeze, to comply with Policy
>>> 10.2 and to ease the introduction of MultiArch, I'm filing bugs
>>> against packages which contain .la files which can be either removed
>>> or stripped of the dependency_libs variable.

>> Policy 10.2 says:

>> These requirements for handling of .la files do not apply to loadable
>> modules or libraries not installed in directories searched by default
>> by the dynamic linker.

> All true, but (...) clearing the dependency_libs field in the .la
> file is still necessary even if the .la file is retained for the
> purposes of things like libltdl. (It is also safe for libltdl usage
> as this relies on a different part of the .la file.)

OK. What is slightly unclear to me, is that "being loaded by libltdl"
is a thing that is external to the package. 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. 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.

> 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 would work for ODBC drivers because they are registered anyway,
so really, (if I understand well) as far as the ODBC libraries and
applications are concerned, they can be anywhere. Nevertheless, IMHO,
it would be "cleaner" if all ODBC drivers made the same choice.

Other loadable libraries (typically plugins / extensions; I'm thinking
of my xchat-guile package here) that are dlopen()ed or loaded using
libltdl, I presume the loading application will have to be fixed to
lead from a multiarch path anyway, so the plugins have to wait for the
app to do it first.

--
Lionel


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110710144816.GA20070@capsaicin.mamane.lu">http://lists.debian.org/20110710144816.GA20070@capsaicin.mamane.lu
 
Old 07-10-2011, 08:57 PM
Neil Williams
 
Default .la file removal, multiarch for plugins

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/
 
Old 07-19-2011, 10:53 PM
Steve Langasek
 
Default .la file removal, multiarch for plugins

Hi Lionel,

On Sun, Jul 10, 2011 at 04:48:16PM +0200, Lionel Elie Mamane wrote:
> >>> To finish an old release goal from Squeeze, to comply with Policy
> >>> 10.2 and to ease the introduction of MultiArch, I'm filing bugs
> >>> against packages which contain .la files which can be either removed
> >>> or stripped of the dependency_libs variable.

> >> Policy 10.2 says:

> >> These requirements for handling of .la files do not apply to loadable
> >> modules or libraries not installed in directories searched by default
> >> by the dynamic linker.

> > All true, but (...) clearing the dependency_libs field in the .la
> > file is still necessary even if the .la file is retained for the
> > purposes of things like libltdl. (It is also safe for libltdl usage
> > as this relies on a different part of the .la file.)

> OK. What is slightly unclear to me, is that "being loaded by libltdl"
> is a thing that is external to the package. 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. 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.

If we're talking about shared libraries, this is a non issue. the .la file
is named like the .so symlink, i.e. without the soname; dlopening a shared
library without specifying an soname is Broken and Wrong. So there's no
reason for us to worry about breaking something that's already entirely
broken.

For plugins / DSOs, it's important to not break compatibility with other
software that might be opening them in a way that references the .la file,
true; but in most cases these are plugins for a specific piece of software,
so we know conclusively whether or not the .la file is used for the lookup.
In this respect, ODBC is a special case. The UnixODBC documentation and
examples certainly all use the .so, not the .la, but ODBC drivers can also
be used directly without going through the driver manager, and if the .la
exists on the system then it's always possible that someone has referenced
it in their odbcinst.ini, too.

So if you are concerned that users are referencing a .la file for an ODBC
driver, it's not a bug for you to leave it in place indefinitely. However,
I think this is a really small compatibility break and would personally not
worry much that this would have an impact on users.

> > 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 would work for ODBC drivers because they are registered anyway,
> so really, (if I understand well) as far as the ODBC libraries and
> applications are concerned, they can be anywhere. Nevertheless, IMHO,
> it would be "cleaner" if all ODBC drivers made the same choice.

I think it would be premature for ODBC drivers to switch to multiarch paths.
There would be no benefit, because the ODBC driver manager doesn't have a
search path for drivers that includes any multiarch paths, so you would have
to hard-code the driver path in the odbcinst.ini - so then it's
architecture-specific anyway and you've gained no ability to use drivers for
multiple architectures side-by-side!

Multiarch is a transition that will have a very long tail, and that's
perfectly ok. There's certainly no need to rush to convert things to new
paths where there isn't a clear and understood benefit.

> Other loadable libraries (typically plugins / extensions; I'm thinking
> of my xchat-guile package here) that are dlopen()ed or loaded using
> libltdl, I presume the loading application will have to be fixed to
> lead from a multiarch path anyway, so the plugins have to wait for the
> app to do it first.

Yes. For examples of how this can be done, feel free to look at the
gdk-pixbuf and glib2.0 patches.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 07-21-2011, 10:51 AM
Philipp Kern
 
Default .la file removal, multiarch for plugins

On 2011-07-19, Steve Langasek <vorlon@debian.org> wrote:
> If we're talking about shared libraries, this is a non issue. the .la file
> is named like the .so symlink, i.e. without the soname; dlopening a shared
> library without specifying an soname is Broken and Wrong. So there's no
> reason for us to worry about breaking something that's already entirely
> broken.

Even if you specify it, it fails now with multiarch. A Java program I use
(that's not packaged yet) dlopen()s /usr/lib/libnss3.so. That one was
shipped in libnss3-1d until recently. So the multiarch-ification leaded
to a FileNotFoundException band-aided by symlinking the above to
/usr/lib/x86_64-linux-gnu/libnss3.so.1d…

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnj2g160.46p.trash@kelgar.0x539.de">http://lists.debian.org/slrnj2g160.46p.trash@kelgar.0x539.de
 
Old 07-21-2011, 11:05 AM
Mike Hommey
 
Default .la file removal, multiarch for plugins

On Thu, Jul 21, 2011 at 10:51:44AM +0000, Philipp Kern wrote:
> On 2011-07-19, Steve Langasek <vorlon@debian.org> wrote:
> > If we're talking about shared libraries, this is a non issue. the .la file
> > is named like the .so symlink, i.e. without the soname; dlopening a shared
> > library without specifying an soname is Broken and Wrong. So there's no
> > reason for us to worry about breaking something that's already entirely
> > broken.
>
> Even if you specify it, it fails now with multiarch. A Java program I use
> (that's not packaged yet) dlopen()s /usr/lib/libnss3.so. That one was
> shipped in libnss3-1d until recently. So the multiarch-ification leaded
> to a FileNotFoundException band-aided by symlinking the above to
> /usr/lib/x86_64-linux-gnu/libnss3.so.1d…

There are 2 bugs involved here: one is that java is looking for the full
path, and another one is that nss-config and nss.pc don't contain the
multiarch path.

(BTW, .la dependency_libs would just have been fine if the full paths
weren't hardcoded)

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110721110553.GA15650@glandium.org">http://lists.debian.org/20110721110553.GA15650@glandium.org
 

Thread Tools




All times are GMT. The time now is 11:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org