Re: Constantly changing libtool
On Thu, 2021-04-15 at 08:33 -0500, Laurence Marks wrote: > In the same way as autoXZY sets up Makefiles in an OS independent > fashion, there should be a way to autoupdate autoXYZ files for each > system without user intervention. (I don't mean automake itself or > similar, I do mean only the local files.) In an ideal world this > would be a macro in configure.ac The problem comes (IMO) from checking in generated files. If you only check in actual source files, not generated files, then you don't run into these issues with different people having different versions of build tools. For GNU make I never check in any files generated by running autotools: I check in configure.ac and Makefle.am and that's all. I don't even check in .po files (latest versions pulled automatically by the build config) or gnulib-installed files (installed during config as well). Of course, this means that everyone who wants to build the software needs to have their own local copy of ALL the tools needed to do so, including autoconf, automake, and libtool (actually we don't use libtool for GNU make but...). There's never a free lunch so you just have to decide which cost is more dear.
Re: Constantly changing libtool
As you say, it has files generated by autotools in a cvs (anonymous), so when checking out there is a clash. --- The software is at http://www.numis.northwestern.edu/Software/, mainly edm & semper-7.0beta. They are both old, not so great but I still use them every year or so for teaching, and there are a few others who use them. They are updated via cvs (yes, they are that old). I am updating them currently (for a class) so they may be changing. At least for edm most of the problems are with fftw-2.1.5 ( http://www.fftw.org/download.html) which is also somewhat old. (Updating the code to use more recent fftw would be a pain.) On Thu, Apr 15, 2021 at 9:27 AM Peter Johansson wrote: > Hi Laurence, > > On 15/4/21 6:35 am, Bob Friesenhahn wrote: > > Most problems seem to stem from packages providing the generated files > > from Autoconf, Automake, and libtool so that end users don't need to > > have the tools available. > > It will be easier for people here to help if you provide a bit more > information about your set-up. Is the problem when building from a > tarball or when building from git/subversion? If the latter, do have you > checked in files generated by autotools into git/subversion, so when > checking out/cloning the source to a system with other autotools > versions, there becomes a clash between versions? > > Cheers, > > Peter > > > > -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Györgyi
Re: Constantly changing libtool
Hi Laurence, On 15/4/21 6:35 am, Bob Friesenhahn wrote: Most problems seem to stem from packages providing the generated files from Autoconf, Automake, and libtool so that end users don't need to have the tools available. It will be easier for people here to help if you provide a bit more information about your set-up. Is the problem when building from a tarball or when building from git/subversion? If the latter, do have you checked in files generated by autotools into git/subversion, so when checking out/cloning the source to a system with other autotools versions, there becomes a clash between versions? Cheers, Peter
Re: Constantly changing libtool
On Thu, 15 Apr 2021, Laurence Marks wrote: In the same way as autoXZY sets up Makefiles in an OS independent fashion, there should be a way to autoupdate autoXYZ files for each system without user intervention. (I don't mean automake itself or similar, I do mean only the local files.) In an ideal world this would be a macro in configure.ac When dealing with updated software there might not be any viable approach other than to install the various Autotools packages using a common installation prefix. Sometimes executing autoreconf --install --force using an existing Autotools installation is a viable solution. Given that all of the software you are using is already released and sometimes very archaic, you are going to need to deal with the situation in front of you. There is not going to be some new release which is somehow going to solve this issue to your satisfaction. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Constantly changing libtool
Unfortunately things are not consistent, and in general have not been for some time. It all depends upon which version has been installed which is sometimes (often) beyond the control/competence of users. Even someone who is moderately competent can have problems. For instance, on my laptop I have both cygwin & Ubuntu; my cluster has Centos. Some of my students have VM and/or Mac-Unix, and who knows what other users in Russia/Japan/etc have -- I can't control that. I typically install autoXYZ on my systems in /use/local, but that is not a reliable or general fix. When moving between machines/OS to test (as gcc & now gfortran are moving targets) I almost always have to reconfig. Libtool is part of the issue, but there are also couplings to aclocal macros and sometimes other components as well. In the same way as autoXZY sets up Makefiles in an OS independent fashion, there should be a way to autoupdate autoXYZ files for each system without user intervention. (I don't mean automake itself or similar, I do mean only the local files.) In an ideal world this would be a macro in configure.ac _ Professor Laurence Marks "Research is to see what everybody else has seen, and to think what nobody else has thought", Albert Szent-Györgyi www.numis.northwestern.edu On Thu, Apr 15, 2021, 08:12 Bob Friesenhahn wrote: > On Wed, 14 Apr 2021, Laurence Marks wrote: > > > It is not timestamp issues, it is version issues -- e.g. libtool 2.4.2 > > versus 2.4.6 (for instance, those are just invented numbers). In many > cases > > aclocal, libtool, ltmain.sh and maybe a few others do not work if they > were > > created with a different autoXYZ version than is on the computer where > they > > are being installed. It seems to be "special" to libtool. > > There has not been a libtool release since 2014 and it is 2021 > already. > > The issues you are complaining about should not be existing for quite > a long time already, and are easily corrected by installing consistent > Autotools versions under the same installation prefix. If you don't > like the archaic versions your system provides, then simply uninstall > (or not use) those packages and install using current Autotools > release versions. > > It is intended that libtool components are installed into the software > which uses them. This assures consistent versions. If the libtool > components were not installed and distributed with the package, then > there could be problems as you describe. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, > https://urldefense.com/v3/__http://www.simplesystems.org/users/bfriesen/__;!!Dq0X2DkFhyF93HkjWTBQKhk!CjQjRsGtyWBePsFky9wEHrKJFYZgwc9ACi_I8ll7bvAa-RaEo1asjDsmsAO-D4rcH7MlDA$ > GraphicsMagick Maintainer, > https://urldefense.com/v3/__http://www.GraphicsMagick.org/__;!!Dq0X2DkFhyF93HkjWTBQKhk!CjQjRsGtyWBePsFky9wEHrKJFYZgwc9ACi_I8ll7bvAa-RaEo1asjDsmsAO-D4oDSZ6wRw$ > Public Key, > https://urldefense.com/v3/__http://www.simplesystems.org/users/bfriesen/public-key.txt__;!!Dq0X2DkFhyF93HkjWTBQKhk!CjQjRsGtyWBePsFky9wEHrKJFYZgwc9ACi_I8ll7bvAa-RaEo1asjDsmsAO-D4od8dCEwg$ >
Re: Constantly changing libtool
On Wed, 14 Apr 2021, Laurence Marks wrote: It is not timestamp issues, it is version issues -- e.g. libtool 2.4.2 versus 2.4.6 (for instance, those are just invented numbers). In many cases aclocal, libtool, ltmain.sh and maybe a few others do not work if they were created with a different autoXYZ version than is on the computer where they are being installed. It seems to be "special" to libtool. There has not been a libtool release since 2014 and it is 2021 already. The issues you are complaining about should not be existing for quite a long time already, and are easily corrected by installing consistent Autotools versions under the same installation prefix. If you don't like the archaic versions your system provides, then simply uninstall (or not use) those packages and install using current Autotools release versions. It is intended that libtool components are installed into the software which uses them. This assures consistent versions. If the libtool components were not installed and distributed with the package, then there could be problems as you describe. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
