Re: running ldconfig
Date: Tue, 14 Mar 2000 18:10:32 +0100 (MET) From: [EMAIL PROTECTED] (Raphael Quinet) Libtool already prints a message telling the user to run "ldconfig" or "ldconfig -v" after installing something, so any user who watches the installation process should know what to do. If somebody reads the install output carefully enough, and understands what that means, maybe (although I went back to the emacs shell that I did the install in and didn't see any such message). But it's buried in a stack of output, if it's there at all. In practice, I start it, go off to do something else, and simply check that it completed successfully. I suspect that this is the common state of affairs. The Gimp Makefile (not libtool) could have an additional call to "ldconfig" or "-(PATH="\$PATH:/sbin" ldconfig) /dev/null" immediately after calling "$(LIBTOOL) --mode=install". But the installation rules in the Makefiles are generated by autoconf/automake and it could be a bit tricky to hack them. Actually, I think libtool should have some kind of "libtool --postinstall"
Re: running ldconfig
Date: Mon, 13 Mar 2000 17:22:50 +0100 (MET) From: [EMAIL PROTECTED] (Raphael Quinet) Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". But "Elf" and "ldconfig" are not too related to each other. Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) It's happened with at least 1.1.17 and 1.1.18. The fact that you're using Solaris explains why you don't have a problem. However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). First, I would like to be sure that it happens with the latest version of the Gimp. I just checked the source for 1.1.17 and 1.1.18, and both of them are distributed with a version of libtool that includes the following on Linux systems: finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir' This is run immediately after installing each library in $libdir. So at least the recent versions of the Gimp _do_ run ldconfig as part of "make install" and you should not have any problems. All that ldconfig -n does is create the links. It doesn't update the cache. ld.so (at least on Linux) needs the cache: ld.so(8) ld.so(8) NAME ld.so/ld-linux.so - dynamic linker/loader DESCRIPTION ld.so loads the shared libraries needed by a program, pre pares the program to run, and then runs it. Unless explicitly specified via the -static option to ld during compilation, all Linux programs are incomplete and require further linking at run time. The necessary shared libraries needed by the program are searched for in the following order o Using the environment variable LD_LIBRARY_PATH (LD_AOUT_LIBRARY_PATH for a.out programs). Except if the executable is a setuid/setgid binary, in which case it is ignored. o From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path. o In the default path /usr/lib, and then /lib. On the other hand, maybe you are having a problem with ld.so.conf, not with ld.so.cache. The latter is updated by ldconfig, but the former can only be modified by hand. I think that it would be wrong for a tool to attempt to modify ld.so.conf automatically, because the order of the directories is important and some modifications could break the whole system. My ld.so.conf is correct (if it weren't, running ldconfig wouldn't solve the problem). I agree that make install should not attempt to edit ld.so.conf. Botching that will trash the system. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: running ldconfig
On Tue, 14 Mar 2000, Robert L Krawitz [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (Raphael Quinet) Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) It's happened with at least 1.1.17 and 1.1.18. The fact that you're using Solaris explains why you don't have a problem. Hmmm... I should have said that I _also_ have an elf-based Solaris system. My development machine at home is a PC running Linux (based on SuSE 6.3, as I described in another message). I did not have any problems on my Linux system, but this is probably because I am so used to running ldconfig after installing anything that I did not even remember that I had to use it. ;-) All that ldconfig -n does is create the links. It doesn't update the cache. ld.so (at least on Linux) needs the cache: You are right, I should have thought about why libtool uses the "-n" option. I think that libtool runs "ldconfig -n" because this is the only option that can be used safely, since it does not require more permissions than the ones for installing the libraries. Libtool already prints a message telling the user to run "ldconfig" or "ldconfig -v" after installing something, so any user who watches the installation process should know what to do. The Gimp Makefile (not libtool) could have an additional call to "ldconfig" or "-(PATH="\$PATH:/sbin" ldconfig) /dev/null" immediately after calling "$(LIBTOOL) --mode=install". But the installation rules in the Makefiles are generated by autoconf/automake and it could be a bit tricky to hack them. -Raphael
Re: running ldconfig
On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache Well, then gimp.m4 does the wrong thing, since after I install a new version of the Gimp I can't use gimp.m4 within autoconf to test for Ah, now I see the problem. Hmm... I guess shared libraries are still largely unexplored for the many ways to do it "right" :( the presence of the Gimp. It's considerably more than "just a cache"; it controls how runtime dynamic linking takes place. On _some_ systems, like linux. Many systems do not even have the notion of ldconfig. 2. only root can run ldconfig (without errors, that is) And make install normally installs software into areas that can only be installed into by root. It is an absolute must, however, that even normal users can install the gimp (remember the long thread on this subject?) 3. not all systems have ldconfig or the same concept of shared libraries as linux (elf or not...) Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". But "Elf" and "ldconfig" are not too related to each other. However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: running ldconfig
On Sun, 12 Mar 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache Well, then gimp.m4 does the wrong thing, since after I install a new version of the Gimp I can't use gimp.m4 within autoconf to test for Ah, now I see the problem. Hmm... I guess shared libraries are still largely unexplored for the many ways to do it "right" :( Hmmm... Strange, because it works for me. Does that happen with the latest version of the Gimp, or with a version older than 1.1.17? Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". But "Elf" and "ldconfig" are not too related to each other. Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). First, I would like to be sure that it happens with the latest version of the Gimp. I just checked the source for 1.1.17 and 1.1.18, and both of them are distributed with a version of libtool that includes the following on Linux systems: finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir' This is run immediately after installing each library in $libdir. So at least the recent versions of the Gimp _do_ run ldconfig as part of "make install" and you should not have any problems. On the other hand, maybe you are having a problem with ld.so.conf, not with ld.so.cache. The latter is updated by ldconfig, but the former can only be modified by hand. I think that it would be wrong for a tool to attempt to modify ld.so.conf automatically, because the order of the directories is important and some modifications could break the whole system. -Raphael
Re: running ldconfig
Date: Sun, 12 Mar 2000 21:44:49 +0100 From: Marc Lehmann [EMAIL PROTECTED] On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: the presence of the Gimp. It's considerably more than "just a cache"; it controls how runtime dynamic linking takes place. On _some_ systems, like linux. Many systems do not even have the notion of ldconfig. That's true, but not particularly germane. Where it does exist, it's a standard part of installation: ldconfig should normally be run by the super-user as it may require write permission on some root owned directo- ries and files. It is normally run automatically at bootup, from /etc/rc, or manually whenever new DLL's are installed. I interpret "manually" as "whatever does the installation", i. e. make install. It is an absolute must, however, that even normal users can install the gimp (remember the long thread on this subject?) Agreed, but that doesn't mean that make install shouldn't attempt to run ldconfig. If users do their own installation and have to set LD_LIBRARY_PATH that's their lookout. System installations should not be subject to this. However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). The hard part is figuring out where ldconfig lives -- on my Linux box it's in /sbin; it doubtless lives elsewhere on other platforms. If the makefile just contains -$(LDCONFIG) it will simply print out a warning message and continue if it doesn't have permission. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: running ldconfig
On Sun, Mar 05, 2000 at 02:16:04PM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: When the Gimp is installed, the make install should run ldconfig (on Elf-based systems, at any rate) so that ld.so picks up the new shared libraries. I don't think so: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache 2. only root can run ldconfig (without errors, that is) 3. not all systems have ldconfig or the same concept of shared libraries as linux (elf or not...) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: running ldconfig
Date: Tue, 7 Mar 2000 16:45:59 +0100 From: Marc Lehmann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] On Sun, Mar 05, 2000 at 02:16:04PM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: When the Gimp is installed, the make install should run ldconfig (on Elf-based systems, at any rate) so that ld.so picks up the new shared libraries. I don't think so: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache Well, then gimp.m4 does the wrong thing, since after I install a new version of the Gimp I can't use gimp.m4 within autoconf to test for the presence of the Gimp. It's considerably more than "just a cache"; it controls how runtime dynamic linking takes place. 2. only root can run ldconfig (without errors, that is) And make install normally installs software into areas that can only be installed into by root. 3. not all systems have ldconfig or the same concept of shared libraries as linux (elf or not...) Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
running ldconfig
When the Gimp is installed, the make install should run ldconfig (on Elf-based systems, at any rate) so that ld.so picks up the new shared libraries. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
