Re: What happened to libtool transitive DSOs?
In regard to: Re: What happened to libtool transitive DSOs?, Bob...: On Thu, 21 Jun 2018, John Calcote wrote: Hi Bob. It's an ubuntu distro release - Linux Mint 18. Why would they do that? GNU Linux and the GNU linker support implicit library dependencies. Sorry to jump into this discussion late, but I wanted to point out that at least RHEL seems to be moving away from using implicit library dependencies. In the RHEL 7.5 (current latest) release notes, chapter 53, on deprecated functionality: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality there's this note: Symbols from libraries linked as dependencies no longer resolved by ld Previously, the ld linker resolved any symbols present in any linked library, even if some libraries were linked only implicitly as dependencies of other libraries. This allowed developers to use symbols from the implicitly linked libraries in application code and omit explicitly specifying these libraries for linking. For security reasons, ld has been changed to not resolve references to symbols in libraries linked implicitly as dependencies. As a result, linking with ld fails when application code attempts to use symbols from libraries not declared for linking and linked only implicitly as dependencies. To use symbols from libraries linked as dependencies, developers must explicitly link against these libraries as well. To restore the previous behavior of ld, use the -copy-dt-needed-entries command-line option. (BZ#1292230) - end excerpt from RHEL release notes Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
On Thu, 21 Jun 2018, John Calcote wrote: Hi Bob. It's an ubuntu distro release - Linux Mint 18. Why would they do that? GNU Linux and the GNU linker support implicit library dependencies. When a library which implicit library dependencies is linked, the libraries it depends on to successfully link are automatically added by the linker, but are not additionally recorded as dependencies. The implicit dependencies (and explicit dependencies) are again used when the program is started by ld.so. Using implicit library dependencies successfully is actually a bit of work but it is very useful to OS distributions which want to update libraries (or groups of libraries) via a package manager without needing to update dependent applications or libraries. The normal libtool operation is to record all of the involved libraries as dependencies since they are all added to the link line. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
On Thu, 21 Jun 2018, Paul T. Bauman wrote: This is correct and bit us as well when Debian-based systems changed this. Our very hackish work around was to insert the following in our configure.ac immediately after AC_OUTPUT(): perl -pi -e 's/link_all_deplibs=no/link_all_deplibs=yes/' libtool OS distributions where shared libraries provide robust implicit dependencies, and where pkg-config or other methods are used to obtain build options, do not like what libtool does. They do not like that libtool adds libraries that the application/library did not explicitly link with. The reason why they do not like this is that if they introduce a different library which has different dependencies then they would like the dependencies to be entirely determined by the new library. This is a very long-standing point of contention. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
Hi Bob. It's an ubuntu distro release - Linux Mint 18. Why would they do that? On Thu, Jun 21, 2018, 9:56 AM Bob Friesenhahn wrote: > On Thu, 21 Jun 2018, John Calcote wrote: > > > > After upgrading to libtool 2.4.2, I find that I now have to specify the > > additional secondary .la files that are listed in the primary .la files' > > dependency_libs property, or I get a link error indicating missing DSOs > on > > the command line (and I can see that libtool is not adding the transitive > > dependencies like it used to. Why was this change made? > > Are you using libtool 2.4.2 as distributed by the FSF or are you using > a modified libtool distributed by an OS vendor? Some OS vendors > modify libtool like this on purpose. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
On Thu, Jun 21, 2018 at 11:56 AM Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Thu, 21 Jun 2018, John Calcote wrote: > > > > After upgrading to libtool 2.4.2, I find that I now have to specify the > > additional secondary .la files that are listed in the primary .la files' > > dependency_libs property, or I get a link error indicating missing DSOs > on > > the command line (and I can see that libtool is not adding the transitive > > dependencies like it used to. Why was this change made? > > Are you using libtool 2.4.2 as distributed by the FSF or are you using > a modified libtool distributed by an OS vendor? Some OS vendors > modify libtool like this on purpose. > This is correct and bit us as well when Debian-based systems changed this. Our very hackish work around was to insert the following in our configure.ac immediately after AC_OUTPUT(): perl -pi -e 's/link_all_deplibs=no/link_all_deplibs=yes/' libtool HTH, Paul ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: What happened to libtool transitive DSOs?
On Thu, 21 Jun 2018, John Calcote wrote: After upgrading to libtool 2.4.2, I find that I now have to specify the additional secondary .la files that are listed in the primary .la files' dependency_libs property, or I get a link error indicating missing DSOs on the command line (and I can see that libtool is not adding the transitive dependencies like it used to. Why was this change made? Are you using libtool 2.4.2 as distributed by the FSF or are you using a modified libtool distributed by an OS vendor? Some OS vendors modify libtool like this on purpose. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
What happened to libtool transitive DSOs?
One of the coolest features (I thought) of libtool was it's ability to allow specification of only the .la files directly required by a library or program when linking. I had code that used libtool 2.2 a while back that worked fine this way. A program P required library A.la, which itself required library B.la. I only had to add A.la to the LDADD variable in my Makefile.am file. After upgrading to libtool 2.4.2, I find that I now have to specify the additional secondary .la files that are listed in the primary .la files' dependency_libs property, or I get a link error indicating missing DSOs on the command line (and I can see that libtool is not adding the transitive dependencies like it used to. Why was this change made? (Or is there something about the entire process I just don't understand?) Thanks in advance! John ___ https://lists.gnu.org/mailman/listinfo/libtool
