Re: .la file status and hint to clear the dependency_libs field
On 2011-05-30 12:16:13 +0100, Simon McVittie wrote: libtool .la files are useful if: * you're linking against a library installed in a directory that isn't searched by the dynamic linker by default (e.g. installing a local library in --prefix=$HOME, and a program that links that library - but this isn't relevant for packaged libraries in /lib or /usr/lib, which are searched by default anyway) [...] My main concern is a make check on a library that depends on some other libraries (which may have been installed via Debian or not, e.g. because I may also want to install versions built with debug options). If Debian no longer provides .la files, will the correct version of the libraries still be picked up? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531164830.gc27...@prunille.vinc17.org
Re: .la file status and hint to clear the dependency_libs field
On Tue, 31 May 2011 18:48:30 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2011-05-30 12:16:13 +0100, Simon McVittie wrote: libtool .la files are useful if: * you're linking against a library installed in a directory that isn't searched by the dynamic linker by default (e.g. installing a local library in --prefix=$HOME, and a program that links that library - but this isn't relevant for packaged libraries in /lib or /usr/lib, which are searched by default anyway) [...] My main concern is a make check on a library that depends on some other libraries (which may have been installed via Debian or not, e.g. because I may also want to install versions built with debug options). If Debian no longer provides .la files, will the correct version of the libraries still be picked up? What reason is there for this not to happen? I've been clearing .la files from the Debian packages of my own upstream packages for some time and routinely use make check and make distcheck. Many packages in Debian have useful make check test programs and these are generally enabled in Debian builds (and will fail the build, causing a release-critical bug, if the tests fail). No such failed builds have been identified as resulting from removal of dependency_libs data in the .la files or even the removal of the .la file itself as long as the sequence of removal is managed. So Debian already has evidence that make check DOES continue to work whether or not .la files exist. It's not as widespread as simple builds without test suites but the range of packages using make check in a Debian build is sufficiently wide that I see no reason to worry about make check differing from standard make. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpt4kXAIzqNx.pgp Description: PGP signature
Re: .la file status and hint to clear the dependency_libs field
On 2011-05-27 00:17:45 +0200, Michael Biebl wrote:
Am 26.05.2011 23:26, schrieb Luk Claes:
There are some good reasons to keep some specific *.la files around,
Just curious: what are these reasons / use case for keeping la files?
They are at least read by libtool. For instance, when building MPFR
(as a normal user):
[...]
7189 stat(/home/vlefevre/software/mpfr/src/libgmp.la, 0x7fffc15d0ae0) = -1
ENOENT (No such file or directory)
7189 stat(/home/vlefevre/software/mpfr/src/libgmp.so, 0x7fffc15d0ae0) = -1
ENOENT (No such file or directory)
7189 stat(/home/vlefevre/software/mpfr/src/libgmp.so, 0x7fffc15d0ae0) = -1
ENOENT (No such file or directory)
7189 stat(/home/vlefevre/software/mpfr/src/libgmp.a, 0x7fffc15d0ae0) = -1
ENOENT (No such file or directory)
7189 stat(/home/vlefevre/x86_64/lib/libgmp.la, 0x7fffc15d0ae0) = -1 ENOENT
(No such file or directory)
7189 stat(/home/vlefevre/x86_64/lib/libgmp.so, 0x7fffc15d0ae0) = -1 ENOENT
(No such file or directory)
7189 stat(/home/vlefevre/x86_64/lib/libgmp.so, 0x7fffc15d0ae0) = -1 ENOENT
(No such file or directory)
7189 stat(/home/vlefevre/x86_64/lib/libgmp.a, 0x7fffc15d0ae0) = -1 ENOENT
(No such file or directory)
7189 stat(/usr/lib/gcc/x86_64-linux-gnu/4.6.1/libgmp.la, 0x7fffc15d0ae0) =
-1 ENOENT (No such file or directory)
7189 stat(/usr/lib/gcc/x86_64-linux-gnu/4.6.1/libgmp.so, 0x7fffc15d0ae0) =
-1 ENOENT (No such file or directory)
7189 stat(/usr/lib/gcc/x86_64-linux-gnu/4.6.1/libgmp.so, 0x7fffc15d0ae0) =
-1 ENOENT (No such file or directory)
7189 stat(/usr/lib/gcc/x86_64-linux-gnu/4.6.1/libgmp.a, 0x7fffc15d0ae0) = -1
ENOENT (No such file or directory)
7189 stat(/usr/lib/libgmp.la, {st_mode=S_IFREG|0644, st_size=927, ...}) = 0
7189 stat(/usr/lib/libgmp.la, {st_mode=S_IFREG|0644, st_size=927, ...}) = 0
7189 stat(/usr/lib/libgmp.la, {st_mode=S_IFREG|0644, st_size=927, ...}) = 0
7189 geteuid() = 1000
7189 getgid() = 1000
7189 getegid() = 1000
7189 getgroups(0, NULL)= 14
7189 getgroups(14, [4, 20, 24, 25, 29, 44, 46, 103, 105, 111, 112, 115, 117,
1000]) = 14
7189 fcntl(5, F_DUPFD, 10) = -1 EBADF (Bad file descriptor)
7189 dup2(0, 5)= 5
7189 open(/usr/lib/libgmp.la, O_RDONLY) = 3
[...]
Either the information provided by /usr/lib/libgmp.la is important
and this file should be kept, or libtool should not attempt to read
the file... unless this doesn't matter for the specific case of
/usr/lib under Debian.
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110530102335.ga25...@prunille.vinc17.org
Re: .la file status and hint to clear the dependency_libs field
On Mon, 30 May 2011 12:23:35 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2011-05-27 00:17:45 +0200, Michael Biebl wrote: Am 26.05.2011 23:26, schrieb Luk Claes: There are some good reasons to keep some specific *.la files around, Just curious: what are these reasons / use case for keeping la files? They are at least read by libtool. That is why dependency_libs can be cleared unconditionally but removal of the .la file itself needs to be done in a sequence where the leaf libraries have their .la files removed first, then the packages which those .la files would have referenced. This is the depended_on listing in the original analysis data: http://release.debian.org/~aba/la/current.txt Packages which are listed with a depended_on listing must not remove the .la file until those dependencies remove their .la files or clear their dependency_libs setting in the .la file. At that point, the file above will list that package as dependency_libs only. libtool will fail if a required .la file is not present - it will not fail if the required .la file is present but has an empty dependency_libs field. Equally, libtool is happy to not need any .la files when dependency_libs fields are all empty. Arguably this utilises a weakness in libtool in that it trusts the contents of the .la file too much, thinking that it is the same content as libtool itself wrote out originally. Once all the dependency_libs are clear, any package not using .la files for plugin loading can then remove their .la files without breaking any other package in the archive. The .la files then (finally) become package-specific and have no impact on other packages. The problem with .la files in Debian is that the data in the .la file is inherently outdated as it is only completely regenerated when every single package in the archive is rebuilt in a specific sequence. There are simpler ways of updating dependency information. libtool's method just doesn't suit what Debian requires. Either the information provided by /usr/lib/libgmp.la is important and this file should be kept, or libtool should not attempt to read the file... unless this doesn't matter for the specific case of /usr/lib under Debian. libtool will not attempt to read the .la file of the next level of dependencies if the dependency_libs field of the immediate dependencies are empty. Compare: $ grep 'dependency_libs=' /usr/lib/*.la Where the output lists explicit file paths (like /usr/lib/libpangoft2-1.0.la) then those listings need to be removed by clearing the entire dependency_libs field. The package build process in Debian deals with providing the information in ways which are controllable within the single package build instead of using, what is essentially, archived data from previous builds as is preserved in the .la files of dependencies. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpGrW12anhNt.pgp Description: PGP signature
Re: .la file status and hint to clear the dependency_libs field
On Mon, 30 May 2011 at 12:23:35 +0200, Vincent Lefevre wrote: They are at least read by libtool. For instance, when building MPFR (as a normal user): [...] Either the information provided by /usr/lib/libgmp.la is important and this file should be kept, or libtool should not attempt to read the file... unless this doesn't matter for the specific case of /usr/lib under Debian. It doesn't matter for the specific case of /usr/lib under Debian. Debian's libtool has appropriate behaviour (read .la files if found, but fall back to just using the real library if not). libtool .la files are useful if: * you're linking against a library installed in a directory that isn't searched by the dynamic linker by default (e.g. installing a local library in --prefix=$HOME, and a program that links that library - but this isn't relevant for packaged libraries in /lib or /usr/lib, which are searched by default anyway) * your build-time dynamic linker doesn't write direct dependencies into shared libraries, or your runtime dynamic linker doesn't respect them (but our linkers work correctly, so this doesn't apply) * you link statically against a library whose upstream doesn't provide a pkg-config .pc file (but if this is the case, please ask them to - it's useful functionality) * you use libltdl to load plugins (this is one legitimate reason for a Debian package to have a .la file accompanying a plugin - but it isn't a reason to have a .la file accompanying a public library) None of these apply to an ordinary public shared library in Debian. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110530111613.ga16...@reptile.pseudorandom.co.uk
Re: .la file status and hint to clear the dependency_libs field
On Mon, May 30, 2011 at 12:16:13PM +0100, Simon McVittie wrote: On Mon, 30 May 2011 at 12:23:35 +0200, Vincent Lefevre wrote: They are at least read by libtool. For instance, when building MPFR (as a normal user): [...] Either the information provided by /usr/lib/libgmp.la is important and this file should be kept, or libtool should not attempt to read the file... unless this doesn't matter for the specific case of /usr/lib under Debian. It doesn't matter for the specific case of /usr/lib under Debian. Debian's libtool has appropriate behaviour (read .la files if found, but fall back to just using the real library if not). s/Debian's// This is upstream libtool behavior. Debian doesn't attempt to diverge from upstream here, because that would basically require rerunning libtoolize on all affected source packages. I know some developers favor this approach, but it's not universally agreed and it indisputably requires more effort from the maintainer to keep the source package buildable with current autotools than to ship the pre-built ones from upstream. So until and unless there's a consensus that packages should be built this way, with build-depends on libtool and the whole nine yards, there's little point in improving libtool in Debian to have more sensible Debian-ish behavior; and conversely it would make Debian less fit as a platform for people doing upstream development and expecting upstream-compatible libtool behavior. If someone wants libtool to behave more sanely in the absence of referenced .la files when doing dynamic linking, please find a way to get that incorporated upstream. :) libtool .la files are useful if: * you're linking against a library installed in a directory that isn't searched by the dynamic linker by default (e.g. installing a local library in --prefix=$HOME, and a program that links that library - but this isn't relevant for packaged libraries in /lib or /usr/lib, which are searched by default anyway) I can't think of a reason this should actually be true on GNU/Linux. A /path/to/lib.so option should give libtool all the information it needs to synthesize the correct rpath options. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: .la file status and hint to clear the dependency_libs field
On Fri, 27 May 2011 00:17:45 +0200 Michael Biebl bi...@debian.org wrote: Am 26.05.2011 23:26, schrieb Luk Claes: There are some good reasons to keep some specific *.la files around, Just curious: what are these reasons / use case for keeping la files? Plugins which us libltdl use the .la file but these methods do not use the dependency_libs setting of the .la file which is where the problems arise. Other plugin methods do not need a .la file. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpAWr8OY4fs4.pgp Description: PGP signature
Re: .la file status and hint to clear the dependency_libs field
On Thu, 26 May 2011 23:26:26 +0200 Luk Claes l...@debian.org wrote: On 05/26/2011 11:55 AM, Michael Biebl wrote: Am 26.05.2011 10:46, schrieb Simon McVittie: On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote: Comments welcome, but foremost I'd like a mass effort to clear the remaining dependency_libs fields! :-) Am I right in thinking that this is the process people should follow? if depended-on: if dependency_libs: clear the dependency_libs else: do nothing (until you are no longer depended-on) Even when depended-on, the dependency_libs field can be cleared, the .la file itself though cannot be removed. else: if dependency_libs: clear the dependency_libs if you are confident that it won't break anything: delete the .la file entirely If the only listing is dependency_libs, then the .la file can be removed as long as the package itself doesn't use the .la for plugins. If it does (and maintainers of such packages already know if their package is affected), clear the dependency_libs. Clearing the dependency_libs is always safe, afaics, so I'd rather say it is something like if depended-on clear dependency_libs else remove *.la files There are some good reasons to keep some specific *.la files around, that's why I'm not aiming at removing them, but at least have the real problem solved. So I suggest: if dependency_libs clear dependency_libs If it is just dependency_libs and there are no plugin issues, it IS safe to remove the .la file rather than adding sed-based processing. See these messages and pages for more information: http://wiki.debian.org/ReleaseGoals/LAFileRemoval http://lists.debian.org/debian-devel/2011/04/msg00055.html http://lists.debian.org/debian-devel/2011/04/msg00199.html -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpbzgRNfZO0P.pgp Description: PGP signature
.la file status and hint to clear the dependency_libs field
Hi Just to remember people that one can follow the status of the .la file dependency_libs clearing goal at Andreas' overview page [1]. A package entry followed by nothing more than a colon (:) means that the package ships an .la file with a cleared dependency_libs field. A package entry that contains 'dependency_libs' means that the dependency_libs field in the .la file still contains references to other libraries. A package entry that contains 'depended-on' means that the list of packages enclosed in brackets '()' have an .la file that contains a dependency_libs field that references this library. So the .la file in this package cannot easily be removed as it would break the mentioned packages. To ease clearing of the dependency_libs field, I'll mention here a sed snippit that can be included in the debian/rules file of an affected package at the end of the install target (aka after the upstream make invocation has completed): sed -i /dependency_libs/ s/'.*'/''/ $(CURDIR)/debian/pkg/usr/lib/la-file Comments welcome, but foremost I'd like a mass effort to clear the remaining dependency_libs fields! :-) Cheers Luk [1] http://release.debian.org/~aba/la/current.txt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dddf76a.1070...@debian.org
Re: .la file status and hint to clear the dependency_libs field
On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote: Comments welcome, but foremost I'd like a mass effort to clear the remaining dependency_libs fields! :-) Am I right in thinking that this is the process people should follow? if depended-on: if dependency_libs: clear the dependency_libs else: do nothing (until you are no longer depended-on) else: if dependency_libs: clear the dependency_libs if you are confident that it won't break anything: delete the .la file entirely Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110526084624.ga25...@reptile.pseudorandom.co.uk
Re: .la file status and hint to clear the dependency_libs field
Hi, sed -i /dependency_libs/ s/'.*'/''/ $(CURDIR)/debian/pkg/usr/lib/la-file Comments welcome, but foremost I'd like a mass effort to clear the remaining dependency_libs fields! :-) gnome-pkg-tools package is already providing a cdbs makefile snippet that does the same thing on all .la files. I've also opened a bug (#586082) a year ago asking if this snippet could be added to cdbs directly, but nothing so far. I guess that step would help a bit in reaching the goal. Cheers Laurent Bigonville [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110526111625.07581...@eldamar.bigon.be
Re: .la file status and hint to clear the dependency_libs field
Am 26.05.2011 10:46, schrieb Simon McVittie: On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote: Comments welcome, but foremost I'd like a mass effort to clear the remaining dependency_libs fields! :-) Am I right in thinking that this is the process people should follow? if depended-on: if dependency_libs: clear the dependency_libs else: do nothing (until you are no longer depended-on) else: if dependency_libs: clear the dependency_libs if you are confident that it won't break anything: delete the .la file entirely Clearing the dependency_libs is always safe, afaics, so I'd rather say it is something like if depended-on clear dependency_libs else remove *.la files -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: .la file status and hint to clear the dependency_libs field
On 11-05-26 at 11:16am, Laurent Bigonville wrote: Hi, sed -i /dependency_libs/ s/'.*'/''/ $(CURDIR)/debian/pkg/usr/lib/la-file Comments welcome, but foremost I'd like a mass effort to clear the remaining dependency_libs fields! :-) gnome-pkg-tools package is already providing a cdbs makefile snippet that does the same thing on all .la files. I've also opened a bug (#586082) a year ago asking if this snippet could be added to cdbs directly, but nothing so far. I guess that step would help a bit in reaching the goal. Cheers Laurent Bigonville [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586082 Do anyone perhaps have an opinion on Peter's suggestion in that bugreport?: I think in order of preference, this should be fixed by patching libtool, or by a debhelper tool, and only then maybe in cdbs. This way you can reach the most packages. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: .la file status and hint to clear the dependency_libs field
Le jeudi 26 mai 2011 à 12:26 +0200, Jonas Smedegaard a écrit : Do anyone perhaps have an opinion on Peter's suggestion in that bugreport?: I think in order of preference, this should be fixed by patching libtool, or by a debhelper tool, and only then maybe in cdbs. This way you can reach the most packages. My dh_devlibs proposal (#534966) still stands. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306413099.4334.99.camel@pi0307572
Re: .la file status and hint to clear the dependency_libs field
[Michael Biebl] Clearing the dependency_libs is always safe, afaics, so I'd rather say it is something like if depended-on clear dependency_libs else remove *.la files Seems like the following would work instead: remove *.la files if depended-on request some binNMUs This is unstable after all, right? (: -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110526160439.gb15...@p12n.org
Re: .la file status and hint to clear the dependency_libs field
On 05/26/2011 11:55 AM, Michael Biebl wrote: Am 26.05.2011 10:46, schrieb Simon McVittie: On Thu, 26 May 2011 at 08:47:06 +0200, Luk Claes wrote: Comments welcome, but foremost I'd like a mass effort to clear the remaining dependency_libs fields! :-) Am I right in thinking that this is the process people should follow? if depended-on: if dependency_libs: clear the dependency_libs else: do nothing (until you are no longer depended-on) else: if dependency_libs: clear the dependency_libs if you are confident that it won't break anything: delete the .la file entirely Clearing the dependency_libs is always safe, afaics, so I'd rather say it is something like if depended-on clear dependency_libs else remove *.la files There are some good reasons to keep some specific *.la files around, that's why I'm not aiming at removing them, but at least have the real problem solved. So I suggest: if dependency_libs clear dependency_libs Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ddec582.5000...@debian.org
Re: .la file status and hint to clear the dependency_libs field
On 05/26/2011 06:04 PM, Peter Samuelson wrote: [Michael Biebl] Clearing the dependency_libs is always safe, afaics, so I'd rather say it is something like if depended-on clear dependency_libs else remove *.la files Seems like the following would work instead: remove *.la files if depended-on request some binNMUs This is unstable after all, right? (: No, breaking things when that can easily be avoided is not preferred. Also not in unstable. Plus some specific *.la files are not meant to be removed at all. And if I'm not mistaken, removing the *.la files and binNMUing the ones that depend on them does not work, some of these would just FTBFS, others could break in unforseen circumstances. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ddec67e.4050...@debian.org
Re: .la file status and hint to clear the dependency_libs field
Am 26.05.2011 23:26, schrieb Luk Claes: There are some good reasons to keep some specific *.la files around, Just curious: what are these reasons / use case for keeping la files? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
