Re: To all port maintainers: libtool
Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: To all port maintainers: libtool
On Fri, 06 Jun 2014 15:02:24 +0200 Alexander Leidinger wrote: Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Essentially .la files are small shell scripts that set some variables so in theory they can be used in all kinds of places, but this seems of little practical value. Libltdl can open and parse .la files (to find the name of the .so file it can dlopen) but it can also work directly with .so files. If a program uses .la files directly then the port can't delete them of course, but so far I haven't encountered such programs. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: To all port maintainers: libtool
On 6/6/14, 9:27 AM, Tijl Coosemans wrote: On Fri, 06 Jun 2014 15:02:24 +0200 Alexander Leidinger wrote: Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Essentially .la files are small shell scripts that set some variables so in theory they can be used in all kinds of places, but this seems of little practical value. Libltdl can open and parse .la files (to find the name of the .so file it can dlopen) but it can also work directly with .so files. If a program uses .la files directly then the port can't delete them of course, but so far I haven't encountered such programs. My main question was non-ports consumers though. What is the impact on them? We're talking a lot about bumping revisions and forcing rebuilds. Will non-ports consumers require rebuild or changes if .la files are missing? Would these non-ports consumers be able to properly build and link without .la files and without modifications? These .la files seem similar to .pc files which are often critical to out-of-tree consumers that assume Linux /usr paths instead of /usr/local paths. -- Regards, Bryan Drewery ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: To all port maintainers: libtool
On Fri, 06 Jun 2014 09:54:37 -0500 Bryan Drewery wrote: On 6/6/14, 9:27 AM, Tijl Coosemans wrote: On Fri, 06 Jun 2014 15:02:24 +0200 Alexander Leidinger wrote: Quoting Tijl Coosemans t...@freebsd.org (from Thu, 5 Jun 2014 18:53:03 +0200): On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. I remember from tests way in the past that not all programs will be happy when the .la files are not there. I remember that I once tried to remove the .la files but it didn't work as the program wanted to open the .la files (after recompile). Maybe libltdl is openening them? Did you make some checks/tests in this regard? Essentially .la files are small shell scripts that set some variables so in theory they can be used in all kinds of places, but this seems of little practical value. Libltdl can open and parse .la files (to find the name of the .so file it can dlopen) but it can also work directly with .so files. If a program uses .la files directly then the port can't delete them of course, but so far I haven't encountered such programs. My main question was non-ports consumers though. What is the impact on them? We're talking a lot about bumping revisions and forcing rebuilds. Will non-ports consumers require rebuild or changes if .la files are missing? If they have a .la file that links to the .la file that went missing then their .la file needs to be rebuilt. Like I said before, this is very similar to .so version bumps. If they have a program (or library) that links to another library that goes from .so.X to .so.(X+1) then their program (or library) needs to be rebuilt too. This is nothing out of the ordinary. If you update a dependency that exists in the ports tree you might have to rebuild stuff that exists outside the tree. This is something you always have to keep in mind. Would these non-ports consumers be able to properly build and link without .la files and without modifications? These .la files seem similar to .pc files which are often critical to out-of-tree consumers that assume Linux /usr paths instead of /usr/local paths. You specifically asked about the impact of the removal of .la files so I restricted my answer to just that, but now I suspect you really want to know about all impacts of USES=libtool. So here it goes. A .la file operates one level below a .pc file so to speak. A libfoo.pc file gives you information about a libfoo package (what compiler and linker flags to use to link with libfoo), while a libfoo.la file will give you information about the dependencies of libfoo. Currently all forms of USES=libtool erase this dependency information or erase the .la file altogether. Suppose you have a program (or library) X outside the ports tree which links to libfoo inside the tree which in turn links to libbar. The command to link X looks roughly like this: libtool --mode=link cc -o X X1.o X2.o -L/usr/local/lib -lfoo Without USES=libtool in the libfoo port, the libtool script will turn that cc command into cc -o X X1.o X2.o -L/usr/local/lib -lfoo -lbar and the resulting binary X will link to both libfoo.so and libbar.so. If X is a library, libtool will also generate X.la which lists libfoo.la and libbar.la as dependencies. Note that these dependencies accumulate. A binary Y that links to library X ends up linking to X.so, libfoo.so and libbar.so. That's what we want to get rid of. With USES=libtool (any form) in the libfoo port, there's no dependency information in libfoo.la so the above libtool command does not add -lbar to the cc command line. X only links with libfoo.so and X.la only lists libfoo.la as a dependency (if it exists, otherwise just -lfoo). This may fail if X uses libbar API directly. The modification you have to make then is to add libbar as a dependency of X in your makefile. USES=libtool exposes these kinds of hidden dependencies. It forces direct dependencies to be listed explicitly. So far the case of libfoo being a shared library. Things may break if it's a static library. If a program X uses functions from a file in the static libfoo.a archive and that file requires functions from libbar then you must also specify -lbar on the command line so it was very convenient for libtool to add -lbar automatically. With USES=libtool (any form) in the libfoo port you must now add libbar as a dependency of X in your makefile even if X doesn't use libbar API directly. We may always revisit this of course but at the time of the creation of USES=libtool this was considered an acceptable loss for the following reasons: 1) Static linking with libtool outside the ports tree is assumed to be used rarely and if it's
Re: To all port maintainers: libtool
On 5/8/14, 5:16 PM, Tijl Coosemans wrote: On Thu, 8 May 2014 21:27:56 +0200 Alexander Leidinger wrote: On Thu, 8 May 2014 00:24:20 +0200 Tijl Coosemans t...@freebsd.org wrote: USES=libtool modifiers :keepla and :oldver. You wasn't explicit, which may be beneficial for people which don't have English as their first language... Is it right that you tell everyone to replace USE_AUTOTOOLS=YES with USES=libtool:keepla:oldver now? No, it is either USES=libtool, USES=libtool:keepla or USES=libtool:oldver. Most ports will eventually use the first form but for the time being many may have to use :keepla or :oldver. To know which one to use you can follow these steps: If a port does not install any libraries always use USES=libtool. If it does, try USES=libtool:keepla. If this causes the major version number of a library to change, use USES=libtool:oldver. You can upgrade USES=libtool:oldver to USES=libtool:keepla if 1) an update to a new version of the port would have changed the library version anyway, or 2) you grep /usr/ports/INDEX-* for your port and find that only a dozen or so other ports depend on it so bumping PORTREVISION on them isn't that bad. You can upgrade USES=libtool:keepla to USES=libtool if you grep /usr/ports/INDEX-* for your port and verify that all of the ports that install .la files also have some form of USES=libtool in their Makefile. Unless the number of dependent ports is small I don't really recommend this. There's no harm in keeping .la files. And for ports with a large dependency chain behind you more or less suggest to keep the modifiers until the ports tree is converted (let's assume a port which is needed by all desktop environments, then we are roughly speaking at about 3k ports or more which depend upon it, which is close enough to the ports tree for this discussion ;-) )? Yes. At some point ports with :oldver will be converted to :keepla. Depending on how many ports these are, this will probably happen in batches of related ports and may need to be coordinated by portmgr. I don't expect this to be something that individual port maintainers will have to worry about. And at another point the dependency records of all .la files will be empty in all ports (currently about 1400 ports left). From then on it will be safe to replace USES=libtool:keepla with USES=libtool. I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? And if there is no impact, I am thoroughly confused on when to keep or not keep them. -- Regards, Bryan Drewery ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: To all port maintainers: libtool
On Thu, 05 Jun 2014 09:39:21 -0500 Bryan Drewery wrote: I don't know what .la files are used for and have no time currently to research it. What is the impact to non-ports consumers of removing .la files? Do they also need patches to make them build? Removing a .la file is somewhat like a library version bump. Anything that depends on it needs to be recompiled. e.g. externProgA links to externLibB which links to portsLibC The links between files are like this: progA - libB.so - libC.so - libC.so (due to libtool overlinking) libB.la - libC.la Linking progA with libB using libtool goes through libB.la. If libC.la disappears the link in libB.la goes stale and linking progA will fail. externLibB needs to be recompiled first. libB.la will then contain -lC instead of libC.la. And if there is no impact, I am thoroughly confused on when to keep or not keep them. Keeping them is a temporary measure. You can take the previous example but with A, B and C all in the ports tree. If you remove libC.la linking port A may fail unless for all ports B, libB.la does not exist or it contains no references to libC.la (for instance because port B has USES=libtool), or you bump PORTREVISION on port B to force recompilation. If you find you have to bump PORTREVISION on too many ports B then just keep the .la file for now. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: To all port maintainers: libtool
On Mon, 12 May 2014 06:58:06 +0200 Matthias Andree wrote: Issue #1: .la files I just received PR 189491 (which proposes USES=libtool:keepla) and looked at it, and thought it good to kill the .la files, so I have tried USES=libtool, without keepla or stuff. The ports are depended on by a lot of other ports so I'd be careful with deleting the .la files. The port also has a patch to flip from -avoid-version to -version-info 0:0:0, and I tried to build with or without. (It should not matter much because libdb does not have non-system requisites, i. e. the port has no LIB_DEPENDS - it only uses libpthreads.) Now, with USES=libtool added, I either have both the foo.so.0 and foo.so.0.0.0 files, with the SONAME being the libdb-4.8.so.0, or if I leave the original upstream -avoid-version setting, I get libdb-4.8.so as SONAME and see libdb-4.8.so.0 files missing. With USES=libtool:keepla, this does not happen. It is utterly unclear to me how that fits together, so my first question is: can you reproduce this behaviour, or is my system goofing up? What concerns me about that is (1) that the file matching the SONAME of the library is merely a symlink, and (2) that the USES=libtool:keepla option apparently might have more effects than documented, namely, adding more library_names with the .0.0.0 and .0 suffix. During compilation and installation the behaviour with and without :keepla is exactly the same. So except for the .la files you should see exactly the same content in the staging area. For ports like this though, that meddle with version-info it's ok to add something like this to the Makefile: # TODO: remove :oldver together with patch-dist::configure USES= libtool:oldver Then it will be dealt with when we can start moving away from :oldver. I already did something like this in graphics/imlib, graphics/jpeg and graphics/tiff. Issue #2: libpthread. An .la file might look like this: [...] # Linker flags that can not go in dependency_libs. inherited_linker_flags=' -pthread' # Libraries that this one depends upon. dependency_libs=' -lpthread' [...] Now, if I remove the .la file, and a slave port that uses libtool to link will then have to list -pthread explicitly on the newer FreeBSD releases (because those fail linking if indirect .so requisites are missing). Yes, but this is no different from other libraries. If some other port needs libpthread it should link to it itself. It's not this port's responsibility. :keepla causes the inherited_linker_flags=-pthread to remain set, so I presume it is safe in this case. However, it does not appear to me that keepla is a temporary measure here, but it looks like it needs to stay forever. :keepla will stay yes, because it's possible for a port to use them, e.g. in combination with libltdl. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: To all port maintainers: libtool
Am 08.05.2014 00:24, schrieb Tijl Coosemans: Hi, I've been asked to write something about USES=libtool to clarify a few things about what it does and why. Tijl, thanks for the effort. I have two findings I do not currently fully understand, perhaps someone who has done more digging into either of these items can help me with them: Issue #1: .la files I just received PR 189491 (which proposes USES=libtool:keepla) and looked at it, and thought it good to kill the .la files, so I have tried USES=libtool, without keepla or stuff. The port also has a patch to flip from -avoid-version to -version-info 0:0:0, and I tried to build with or without. (It should not matter much because libdb does not have non-system requisites, i. e. the port has no LIB_DEPENDS - it only uses libpthreads.) Now, with USES=libtool added, I either have both the foo.so.0 and foo.so.0.0.0 files, with the SONAME being the libdb-4.8.so.0, or if I leave the original upstream -avoid-version setting, I get libdb-4.8.so as SONAME and see libdb-4.8.so.0 files missing. With USES=libtool:keepla, this does not happen. It is utterly unclear to me how that fits together, so my first question is: can you reproduce this behaviour, or is my system goofing up? What concerns me about that is (1) that the file matching the SONAME of the library is merely a symlink, and (2) that the USES=libtool:keepla option apparently might have more effects than documented, namely, adding more library_names with the .0.0.0 and .0 suffix. Issue #2: libpthread. An .la file might look like this: [...] # Linker flags that can not go in dependency_libs. inherited_linker_flags=' -pthread' # Libraries that this one depends upon. dependency_libs=' -lpthread' [...] Now, if I remove the .la file, and a slave port that uses libtool to link will then have to list -pthread explicitly on the newer FreeBSD releases (because those fail linking if indirect .so requisites are missing). :keepla causes the inherited_linker_flags=-pthread to remain set, so I presume it is safe in this case. However, it does not appear to me that keepla is a temporary measure here, but it looks like it needs to stay forever. Any insights, from anyone? Cheers, Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
