Re: config.guess and freedom (was: 1.8 and mkdir_p)
On Tue, 2004-01-13 at 18:18, Bob Friesenhahn wrote: > On Tue, 13 Jan 2004, Bob Proulx wrote: > > > > > If the releases are all that similar, why not use: > > > > > > i686-GnuLinux-* > > > > > > as your test, and provide the "popular" distributions in the 3rd field? > > > > > > The "magic" command has a large database of selections on it; using this > > > sort of mechanism should greatly ease the burder on the config.* > > > maintainers. > > > > That sounds like the architecture and philosophy of imake. > > Not exactly. Well, if following Harlan's intention then: yes. > The philosophy of imake is that the imake configuration > is primarily vendor maintained. IMHO, this is functionally basically the same as Harlan's intention: AFAIU, he wants to use the value returned by config.guess as a key to look up "distribution"-/"vendor"-supplied settings for a system. This is basically the same working principle as imake's and therefore suffers from the same deficiencies and drawbacks. Now he is facing what in AI is known as "symbol grounding problem": "Any definition of any symbol can be further fine-grained and is only valid with certain contexts/views." Less abstract: It's the old "Why not "i386-redhat-linux-glibc2-kernel2.2.22-XFree4.3-...-strawberries'n'cream"? question. This question is not solvable in general. Any chosen definition of a symbol (the tuple) is only applicable from given contexts/views (here: by certain applications; the tuple seems to be well suited to libtool's or gcc's demands). Beyond these contexts/views you'll always find cases where you have to resort to other means. Apparently Harlan's intention is such a case and therefore is doomed to fail in longer terms. Whatever definition has been choosen, you will always be able to find a case where someone wants to extend the tuple. Ralf
Odd warning
Hi, After having upgraded from automake-1.8.1 to automake-1.8.2 (And having modified some Makefile.ams), I received this warning from automake: configure.ac:16: version mismatch. This is Automake 1.8.2, configure.ac:16: but the definition used by this AM_INIT_AUTOMAKE configure.ac:16: comes from Automake 1.8.1. You should recreate configure.ac:16: aclocal.m4 with aclocal and run automake again. WARNING: `automake-1.8' is probably too old. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . && /bin/sh ./config.status Makefile I don't understand why this warning is issued. To my understanding automake-1.8.1 and automake-1.8.2 both should implement the automake-1.8 API and therefore should be sufficiently compatible. Therefore, I don't understand why 1. this warning is required at all. 2. automake doesn't automatically try to do what it recommends the user to do manually: running aclocal and automake. Ralf
Re: 1.8 and mkdir_p
On Wed, 14 Jan 2004, Scott James Remnant wrote: > On Tue, 2004-01-13 at 21:25, Harlan Stenn wrote: > > > I think you are missing my point. > > > > The information I am talking about is used for *runtime* decisions - very > > likely in a script that is in a shared directory used by many different > > architectures. > > > Oh, well, config.guess isn't designed for that -- it's for compile time > decisions. Config.guess is maintained separately from Automake. It is only distributed by Automake. While it could be viewed as a build tool, it is really a useful utility in its own right and should be treated as such. Regardless of its author's original intentions, I have been known to use config.guess in login scripts, DejaGnu scripts, or for other non-autoconf situations. One handy use when building for multiple architectures is to use config.guess to supply part of the build directory name so that it is very easy to manage heterogeneous builds within one file system. I agree with Harlan that config.guess should produce similar results for Linux as for other operating systems, but apparently the Linux folks disagree since they have intentionally avoided discriminating between Linux distributions. Even Linux 'uname -a' is useless to determine the Linux distribution name. It is way to late to even think about changing things now. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: config.guess and freedom (was: 1.8 and mkdir_p)
I bet you have never tried to deploy this in the real world in an environment with a useful number of heterogeneous OS installations running at different OS rev levels. In my experience this simply doesn't scale. Especially if it gets used in somebody's shell RC files. Your approach still "special cases" linux distributions, and is still limited to detecting libc versions. There are a lot of other places this can be be useful, and requiring separate tests for what is generally determinable by using the OS name and version (distribution name for linux) has been a far faster and simpler way to go in my experience. H -- > Harlan Stenn wrote: > > > If the releases are all that similar, why not use: > > > > i686-GnuLinux-* > > > > as your test, and provide the "popular" distributions in the 3rd field? > > This is a little more reasonable, since it allows to check for Linux with > a single test. But the fundamental problem remains: your proposal still makes > it hard to fork a new distribution. > > > for specifying > > what OS partition to mount for automounters, just to name one example. > > An autoconf test should do it: Test for /afs, /auto and similar. > > > Different OS versions often have different libc versions (for example), so > > while it may be easy to run a SunOS5 binary on later versions of the OS, it > > may not be possible to run a SunOS9 binary on earlier versions of the OS. > > This too is best made with an autoconf test. Find attached an autoconf > test for glibc >= 2.1. You can adapt it to test for any glibc version. > > Bruno > > > === > # glibc21.m4 serial 2 (fileutils-4.1.3, gettext-0.10.40) > dnl Copyright (C) 2000-2002 Free Software Foundation, Inc. > dnl This file is free software, distributed under the terms of the GNU > dnl General Public License. As a special exception to the GNU General > dnl Public License, this file may be distributed as part of a program > dnl that contains a configuration script generated by Autoconf, under > dnl the same distribution terms as the rest of that program. > > # Test for the GNU C Library, version 2.1 or newer. > # From Bruno Haible. > > AC_DEFUN([jm_GLIBC21], > [ > AC_CACHE_CHECK(whether we are using the GNU C Library 2.1 or newer, > ac_cv_gnu_library_2_1, > [AC_EGREP_CPP([Lucky GNU user], > [ > #include > #ifdef __GNU_LIBRARY__ > #if (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 1) || (__GLIBC__ > 2) > Lucky GNU user > #endif > #endif > ], > ac_cv_gnu_library_2_1=yes, > ac_cv_gnu_library_2_1=no) > ] > ) > AC_SUBST(GLIBC21) > GLIBC21="$ac_cv_gnu_library_2_1" > ] > ) >
Re: 1.8 and mkdir_p
> > I think you are missing my point. > >=20 > > The information I am talking about is used for *runtime* decisions - very > > likely in a script that is in a shared directory used by many different > > architectures. > Oh, well, config.guess isn't designed for that -- it's for compile time > decisions. You are clearly joking! I am not saying that I want to run config.guess as part of every shell RC file. I am saying the information that *should* be returned by config.guess (in its original spec) are sometimes needed for runtime decisions in a variety of places. > uname -s, test -x /bin/rpm, test -x /bin/dpkg > > are probably what you're after. Not at all. I am talking about problems that you apparently have never had to really solve. H
Re: 1.8 and mkdir_p
On Tue, 2004-01-13 at 21:25, Harlan Stenn wrote: > I think you are missing my point. > > The information I am talking about is used for *runtime* decisions - very > likely in a script that is in a shared directory used by many different > architectures. > Oh, well, config.guess isn't designed for that -- it's for compile time decisions. uname -s, test -x /bin/rpm, test -x /bin/dpkg are probably what you're after. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Internal Error
Slowly giving up.. autoconf cvs with Eric Sunshine's SHELL patch applied, but
maybe not propagated to all the executables involved, and automake
cvs of today, NetBSD-1.6ZG/i386, in the automake directory:
% sh bootstrap
Found no shell that has working shell functions.
Please tell [EMAIL PROTECTED] about your system.
Use of uninitialized value in exists at ./automake.tmp line 4545, line 1.
Use of uninitialized value in concatenation (.) or string at ./automake.tmp line 4545,
line 1.
automake.tmp:
automake.tmp: ## Internal Error ##
automake.tmp:
automake.tmp: unrequested trace `'
automake.tmp: Please contact <[EMAIL PROTECTED]>.
at automake-1.8a/Automake/Channels.pm line 562
Automake::Channels::msg('automake','','unrequested trace `\'') called at
automake-1.8a/Automake/ChannelDefs.pm line 191
Automake::ChannelDefs::prog_error('unrequested trace `\'') called at
./automake.tmp line 4545
Automake::scan_autoconf_traces('configure.ac') called at ./automake.tmp line
4733
Automake::scan_autoconf_files() called at ./automake.tmp line 7267
Any hints?
Cheers,
Patrick
Re: config.guess and freedom (was: 1.8 and mkdir_p)
If there was a version number in the Vendor field I'd be lots happier. In the RH distros I've seen (and the config.guess output on those boxes) I have still only seen "pc" for the Vendor field. H -- > On Tue, 2004-01-13 at 13:43, Bruno Haible wrote: > > Harlan Stenn wrote: > > > > > If the releases are all that similar, why not use: > > > > > > i686-GnuLinux-* > > > > > > as your test, and provide the "popular" distributions in the 3rd field? > > > > This is a little more reasonable, > > How would that be basically different from what most Linux distributors > do these days? > > i386-redhat-linux-gnu > i586-suse-linux-gnu > > Essentially the main difference would be providing a distribution > version number. > > But that's such a marginal detail which apparently is negligible for the > vast amount of applications to config.guess. If you really need it, you > can still obtain it in other ways (grep'ing /etc/*-release). > > Ralf > >
Re: 1.8 and mkdir_p
I think you are missing my point.
The information I am talking about is used for *runtime* decisions - very
likely in a script that is in a shared directory used by many different
architectures.
While it may be one possible implementation to run a configure script at
startup time, it quickly becomes more difficult (and expensive) to run it
whenever a new process starts.
Also, your goal may be a laudable long-term effort, but we need to evolve to
that place; it won't happen overnight and forcing people (with the current
behavior) to find alternate means to determine this information only slows
progress toward the goal we both seem to have in common.
And N people writing N different autoconf macros does not do much to
"advance the art".
H
--
> Harlan Stenn wrote:
> > > The differences between ALL of the various linux-gnu implementations are
> > > so slight that they are far more suited to feature tests than something
> > > like this.
> >
> > Are you really serious? ...
> >
> > - RC files?
> > - packaging mechanism?
> > - automount filesystem selection based on different OS versions?
>
> These are good examples for how autoconf may be useful:
> - RC files: Check for the existence of /{etc,sbin}/{rc.d,init.d}.
> - Packaging mechanism: Test for /bin/rpm and {/usr,}/bin/apt
> - automount filesystem selection: Check for /afs. Check for
> /etc/init.d/autofs or for autofs in /proc/modules. Check for amd...
>
> Remember: an autoconf macro is written once. A list of Linux distributions
> that have a particular feature must be maintained forever.
>
> Bruno
>
Re: config.guess and freedom (was: 1.8 and mkdir_p)
On Tue, 2004-01-13 at 13:43, Bruno Haible wrote: > Harlan Stenn wrote: > > > If the releases are all that similar, why not use: > > > > i686-GnuLinux-* > > > > as your test, and provide the "popular" distributions in the 3rd field? > > This is a little more reasonable, How would that be basically different from what most Linux distributors do these days? i386-redhat-linux-gnu i586-suse-linux-gnu Essentially the main difference would be providing a distribution version number. But that's such a marginal detail which apparently is negligible for the vast amount of applications to config.guess. If you really need it, you can still obtain it in other ways (grep'ing /etc/*-release). Ralf
Re: DOBMWFMR, and smiled some
Free Cable%RND_SYB TV rich cabdriver homology embroil patient since powell heroes chromate inductor testy leigh catalina concierge plagioclase dewdrop gibson myriad interrogatory curium slag alteration aerosol simons mackey selenite halfhearted sneaky lawmake postwar annunciate verge bathroom craftsmen gsa rig televise
STRICTLY COFIDENTIAL
FROM: THE DESK OF PRINCE TEODORO NGUEMA MBASOGO (JR
TEL.:-0034-677256839. FAX 0034-635923852.
E-MAIL:[EMAIL PROTECTED]
I AM PRINCE TEODORO NGUEMA MBASOGO {JR}. THE SON OF PRESIDENT TEODORO
OBIANG NGUEMA MBASOGO, THE PRESIDENT OF THE REPUBLIC OF EQUATORIAL
GUINEA. AND I AM PRESENTLY LIVING IN {MADRID-SPAIN} EUROPE AND I SPEAK
SPANISH VERY WELL AS IT IS OUR NATIVE LANGUAGE.
MY FATHER HAS INSTRUCTED ME TO LOOK FOR A RELIABLE PARTNER WHO WILL
TAKE CARE OF HIS FUND NOW DEPOSITED AT RIGGS BANK,DUPONT CIRCLE
BRANCH,WASHINGTON USA.
THE AMOUNT IN THE BANK IS THE SUM OF US$150 MILLION. THE JUST
DEPARTMENT IS TRYING TO QUERRY WHY SUCH A HUGE AMOUNT OF MONEY IS IN MY FATHER'S
ACCOUNT AND WE WANT TO MOVE THE MONEY OUT OF UNITED STATES OF AMERICA
TO SPAIN WHERE WE KNOW BANKS THAT CAN KEEP THE MONEY WITHOUT RAISING EYE
BROW.
WHY WE NEED YOU IS THIS,WE NEED A TRUSTWORTHY SOMEBODY WHO WILL OPEN AN
ACCOUNT IN SPAIN AND THE MONEY WILL BE MOVED FROM THE U.S.A ACCOUNT TO
THE NEW ACCOUNT IN SPAIN.
AFTER OPENING OF THE ACCOUNT WITH THE BANK IN SPAIN, WE SHALL GIVE YOU
AN AUTHORIZATION TO RIGGS BANK TO TRANSFER THE MONEY BIT BY BIT INTO
THE ACCOUNT YOU HAVE OPENED IN SPAIN.
WE WANT SOMEBODY WHO HAS NO CONNECTION WITH US SO AS TO AVOID ANY LINK
TO OUR FAMILY. THIS MONEY IS FREE FROM DRUG AND LAUNDERING AS WAS PAID
INTO MY FATHER'S ACCOUNT BY EXXON MOBIL FOR CRUDE OIL LICENSE IN OUR
COUNTRY.
IF YOU ARE READY TO HELP,PLEASE REPLY IMMEDIATELY AND GIVE ME YOUR FULL
CONTACT INFORMATIONS SUCH AS YOUR FULL NAME/ADDRESS, TEL/FAX NUMBERS.
WE SHALL GIVE YOU 15% OF ANY AMOUNT TRANSFERED INTO THE NEW ACCOUNT AND
YOU WILL HELP US IN INVESTING THE REST OF THE MONEY.
THANK YOU.
BEST REGARDS.
TEODORO MBASOGO{JR}
Re: UURAJQ, entire top floor
Our US Licensed Doctors will Prescribes Your Medication For Free Medications Shipped Overnight To Your Do. show Me more prong floor typhon melcher dash crt methane classic portrayal fundamental namesake sagittarius coda pollster aphorism buttery soya blame circumsphere cotman disciple patch colonnade crossover pernicious impractical palindrome maudlin patrimonial thyroglobulin elton enumerable angling dinghy congo morrill procedural racket scottish endicott hundredfold kidnapping maggoty dang chaplain author protest tiptoe everglades fortitude lanthanum mitten complementary luxury switzerland can't led downslope pershing burn den compelling flit sheik penitentiary linden scar dearborn alistair bowmen victoria squishy crosby mescal bijection anthropomorphic prejudice elmhurst refrain defendant conrad injun shall chit cacao handy exotic bind deadhead euler graze encumber isotropic allan scherzo bridgeable proscription radix commodore tunis cognition concomitant estimate amygdaloid query thirst anhydride copperfield xenophobia snake charybdis scylla contumacy septic burgeon area hansen melissa spidery pervert calvinist focal contextual blackjack glacier franchise bungle paulo curry again brunt diaper boyfriend hansom porch winnow ammoniac stalin isocline chagrin rembrandt fold downstream mart equine compliant sleuth bridle effete atlantica breach chalcedony egotist conrad inescapable flatworm siam shutout prosecutor backstitch gallstone thresh cascade contralto thump crumble alluvial boyhood physiochemical rubicund medico primitivism sulfite chromosphere cassock histogram scarface emilio deform toolmake conjuncture vhf carl bleach pick affinity azure angling sunfish kilo size deus shelby luxembourg rutile bidden showboat conjugal constraint carbonic retrofitted vogel cathodic phenolic bufflehead collie airpark cetera satisfy eaton degassing leninist scorn timetable bluejacket carney bayberry socket farrell alumina fibrous beget emmanuel explicit elk portraiture houghton befitting needlepoint radioastronomy neurasthenic amaze sears barometer december bust manumit accept airframe doric someone battery dominique buxtehude obtrusive honest embezzle pensacola inspector leonid booze cartesian question camellia coma butt decompression flown tool altruist paramus foster offhand quadrature potential impossible codeword brave serendipitous rudolph contradistinction clarence wilmington oceanside erlenmeyer miller blackout earthmen bail harley neap beseech susanne mimeograph documentation politburo argonaut thomson coercion businessmen parr abode ghoul gop wretch imperceptible ukraine coeditor covalent decatur ran chlorine norfolk lindholm docket fm hydra slate illustrate indirect amorphous webster cast uniaxial monogamous assiduity cheesecake capstan caw sherrill lit eastman belmont quadrature emerald hollingsworth clog continent dubhe ellison bondsman bicker champagne goode any septa conner goa
make distcheck problem
I have the following in a Makefile.am: if BUILD_SRC_BEOS_SUBDIR d_beos = beos endif SUBDIRS = $(d_beos) where BUILD_SRC_BEOS_SUBDIR is from an AM_CONDITIONAL in configure.in. BUILD_SRC_BEOS_SUBDIR is not defined because I'm not building on BeOS. The directory structure is top level top level/src top level/src/beos If I run make distcheck in the top level directory, it bombs out at one point because the beos subdir doesn't exist. Is this a bug in automake? Is there any way to work around it? I am not running on [...] make[2]: Entering directory `/home/lhecking/gnuplot/gnuplot-3.8k.0/_build/src' list='beos'; for subdir in $list; do \ if test "$subdir" = .; then :; else \ test -d "../gnuplot-3.8k.0/src/$subdir" \ || mkdir "../gnuplot-3.8k.0/src/$subdir" \ || exit 1; \ (cd $subdir && \ make \ top_distdir="../../gnuplot-3.8k.0" \ distdir="../../gnuplot-3.8k.0/src/$subdir" \ distdir) \ || exit 1; \ fi; \ done /bin/bash: cd: beos: No such file or directory make[2]: *** [distdir] Error 1 make[2]: Leaving directory `/home/lhecking/gnuplot/gnuplot-3.8k.0/
Re: config.guess and freedom (was: 1.8 and mkdir_p)
On Tue, 13 Jan 2004, Bob Proulx wrote: > > > If the releases are all that similar, why not use: > > > > i686-GnuLinux-* > > > > as your test, and provide the "popular" distributions in the 3rd field? > > > > The "magic" command has a large database of selections on it; using this > > sort of mechanism should greatly ease the burder on the config.* > > maintainers. > > That sounds like the architecture and philosophy of imake. Not exactly. The philosophy of imake is that the imake configuration is primarily vendor maintained. This is/was reasonable for X11 since most vendors were interested in supporting/offering X11. Autoconf does not benefit from that environment. Long ago I wrote a magazine article about Autoconf and feature-based testing (see "http://www.byte.com/art/9711/sec4/art2.htm";). At that time feature-based testing was relatively new and was being incorporated in open source packages. Based on the ease of installing most open source packages that provide a "configure" script, it seems that feature-based testing has proven to be a resounding success. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: utility programs used during build
> "Warren" == Warren Turkal <[EMAIL PROTECTED]> writes: Warren> Is there any analysis on what it would take to create utility Warren> programs that are only used during build in a crosscompiled Warren> environment in automake? Warren> I and working on the libX11 for Freedesktop.org and it builds Warren> a file and uses it during installation, but does not install Warren> it. I am under the impression that automake does not support Warren> this right now. What would be needed to add support for this Warren> feature. I think your plan as posted on the patch list is a good start. I always liked the gcc-style names like `CC_FOR_BUILD', `CFLAGS_FOR_BUILD'; they always seemed the easiest to understand. (Other folks have suggested BUILD_CC, BUILD_CFLAGS, etc. Which, really, aren't that much harder.) Having a `build_' prefix for primaries makes sense to me. For autoconf it would be nice if you could tell it "now I want to do checks on the host compiler" and have it change the definition of CC (and other flags), have a new build-specific config.h, etc. The required changes might be extensive. I agree with Alexandre that we don't have to support target, just host and build. Well, really it might be nice to clean up target library support, but I wouldn't recommend it unless you have a real need; it is pretty messy. Tom
Re: GNU Automake 1.8.2 released
On Tue, Jan 13, 2004 at 02:59:23PM +, Lars Hecking wrote: > Alexandre Duret-Lutz writes: > > I'm embarassed to announce the release of Automake 1.8.2. > > And rightly so ;-) > > It fails two tests here on Solaris 9 - acloca14.test and conflnk3.test. Thanks for the report. These look like harmless spurious failures. Please people, do send such bug reports to [EMAIL PROTECTED] not to the main list. This is what `make check' asks, this is what the annoncement text asks, this is also what the annoncement headers ask. I don't know what else I can do (suggestions welcome). > ...checking for a BSD-compatible install... /usr/local/gnu/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > configure: creating ./config.status > /bin/bash ./config.status > config.status: creating Makefile > make: Nothing to be done for `all'. > aclocal.m4 stamp differ: char 42, line 1 > FAIL: acloca14.test > > If this test does what I think it does (comparing a generated aclocal.m4 > with a non-generated) it fails because the former was generated by the > installed version of aclocal, and the actual difference is caused by the > version strings inserted by aclocal. Unless the suggestion below makes sense, could you send the full output of the test? I don't have enough context here and would also like to see the very first line, which shows $PATH. The point is that PATH is sets so that the locally built aclocal occurs before any installed version. If aclocal.m4 and stamp differ by the version string, then it means PATH was reset at some point. It looks like the same bug as http://sources.redhat.com/ml/bug-automake/2003/msg00534.html (i.e., a shell setup that mistakenly resets PATH in non-interactive shells), the only difference being that you already have an automake-1.8 installed. > I _think_ the other test fails because it uses test -e, which is not > supported in Solaris' /bin/sh: Surely that's it. I'll change this test to skip platforms where `test -e' does not work.
Re: config.guess and freedom (was: 1.8 and mkdir_p)
Harlan Stenn wrote: > The good news and bad news is that your position is a POLICY decision. > > I am talking about a MECHANISM tool. Agreed. But it is not a mechanism of automake. Nor should the autotools support it since it embodies a diametrically opposed philosophy from the one the autotools supports. A table driven method of system identification would be in opposition to the design architecture of the autotools. > Well, in the old days we used sysIII and sysV in various incarnations to > avoid coding a different value for every reseller of those OSes. Simliarly > for the different BSD releases. And those days of #ifdef SYSV were terrible days for portability. You say resellers as if they were truly the same (and some were), but most were true forks. Unfortunately it sounds like you want to recreate that environment again today. I still live on one of those OSs which is similar, but slightly different, from other systems. Porting software to it is always a problem. Especially when someone has a table of systems to determine whether to call /bin/grep or /usr/bin/grep or whatever and does not have HP-UX in the table. I am always hacking on people's misguided attempts at portability. And life is interesting all over again with HP-UX on ia64. > If the releases are all that similar, why not use: > > i686-GnuLinux-* > > as your test, and provide the "popular" distributions in the 3rd field? > > The "magic" command has a large database of selections on it; using this > sort of mechanism should greatly ease the burder on the config.* > maintainers. That sounds like the architecture and philosophy of imake. Bob
Re: config.guess and freedom (was: 1.8 and mkdir_p)
Harlan Stenn wrote: > If the releases are all that similar, why not use: > > i686-GnuLinux-* > > as your test, and provide the "popular" distributions in the 3rd field? This is a little more reasonable, since it allows to check for Linux with a single test. But the fundamental problem remains: your proposal still makes it hard to fork a new distribution. > for specifying > what OS partition to mount for automounters, just to name one example. An autoconf test should do it: Test for /afs, /auto and similar. > Different OS versions often have different libc versions (for example), so > while it may be easy to run a SunOS5 binary on later versions of the OS, it > may not be possible to run a SunOS9 binary on earlier versions of the OS. This too is best made with an autoconf test. Find attached an autoconf test for glibc >= 2.1. You can adapt it to test for any glibc version. Bruno === # glibc21.m4 serial 2 (fileutils-4.1.3, gettext-0.10.40) dnl Copyright (C) 2000-2002 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program dnl that contains a configuration script generated by Autoconf, under dnl the same distribution terms as the rest of that program. # Test for the GNU C Library, version 2.1 or newer. # From Bruno Haible. AC_DEFUN([jm_GLIBC21], [ AC_CACHE_CHECK(whether we are using the GNU C Library 2.1 or newer, ac_cv_gnu_library_2_1, [AC_EGREP_CPP([Lucky GNU user], [ #include #ifdef __GNU_LIBRARY__ #if (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 1) || (__GLIBC__ > 2) Lucky GNU user #endif #endif ], ac_cv_gnu_library_2_1=yes, ac_cv_gnu_library_2_1=no) ] ) AC_SUBST(GLIBC21) GLIBC21="$ac_cv_gnu_library_2_1" ] )
Re: GNU Automake 1.8.2 released
Alexandre Duret-Lutz writes: > I'm embarassed to announce the release of Automake 1.8.2. And rightly so ;-) It fails two tests here on Solaris 9 - acloca14.test and conflnk3.test. ...checking for a BSD-compatible install... /usr/local/gnu/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes configure: creating ./config.status /bin/bash ./config.status config.status: creating Makefile make: Nothing to be done for `all'. aclocal.m4 stamp differ: char 42, line 1 FAIL: acloca14.test If this test does what I think it does (comparing a generated aclocal.m4 with a non-generated) it fails because the former was generated by the installed version of aclocal, and the actual difference is caused by the version strings inserted by aclocal. I _think_ the other test fails because it uses test -e, which is not supported in Solaris' /bin/sh: config.status: creating Makefile config.status: creating sdir/Makefile config.status: linking ./src2 to sdir/dest2 config.status: linking ./sdir/src3 to sdir/dest3 config.status: linking ./src to dest config.status: linking ./sdir/dest2 to dest4 config.status: linking ./src to dest5 ./conflnk3.test: test: argument expected FAIL: conflnk3.test
AC_CONFIG_FILES and Makefile.am
On one project, I have over 60 entries in AC_CONFIG_FILES that are derived from Makefile.ams. This is getting to be irritating to maintain. Is there any good reason why there isn't an AM_CONFIG_MAKEFILES macro that computes a list of makefiles by following SUBDIRS variables in the Makefile.ams, and calls AC_CONFIG_FILES appropriately? (I'll implement it myself if I have to) -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: 1.8 and mkdir_p
Harlan Stenn wrote:
> > The differences between ALL of the various linux-gnu implementations are
> > so slight that they are far more suited to feature tests than something
> > like this.
>
> Are you really serious? ...
>
> - RC files?
> - packaging mechanism?
> - automount filesystem selection based on different OS versions?
These are good examples for how autoconf may be useful:
- RC files: Check for the existence of /{etc,sbin}/{rc.d,init.d}.
- Packaging mechanism: Test for /bin/rpm and {/usr,}/bin/apt
- automount filesystem selection: Check for /afs. Check for
/etc/init.d/autofs or for autofs in /proc/modules. Check for amd...
Remember: an autoconf macro is written once. A list of Linux distributions
that have a particular feature must be maintained forever.
Bruno
Re: utility programs used during build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warren Turkal wrote: | Is there any analysis on what it would take to create utility programs that | are only used during build in a crosscompiled environment in automake? | | I and working on the libX11 for Freedesktop.org and it builds a file and | uses it during installation, but does not install it. I am under the | impression that automake does not support this right now. What would be | needed to add support for this feature. Does this work? nodist_PROGRAMS = installtool install: installtool - -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAA9x2FRMICSmD1gYRAtCyAJ9iO0eW5/THZIhH7qPAsxbOuh9IeQCgiB6p EYf81/l4CKfrlrM+/tgJL0Y= =TxXU -END PGP SIGNATURE-
Re: config.guess and freedom (was: 1.8 and mkdir_p)
> Harlan Stenn wrote (meaning "Linux distribution" when he writes "OS"): > > help tool maintainers make choices > > about how things that are hard to find out otherwise (like OS-based > > choices). > > ... > > everybody who wants to make OS-level decisions has to code their own tests > > to figure out the OS name. > > The point is: Don't make choices at all based on the distribution's name! > Not only it limits the freedom to create new distributions, it's also more > costly to maintain a list of features/commands/install-locations/etc. > depending on the distribution, than to write an autoconf test. The good news and bad news is that your position is a POLICY decision. I am talking about a MECHANISM tool. It is unreasonable to expect tool/package maintainers to do this. It is unreasonable to expect that tool/package maintainers are the only ones who need to do this. config.guess is also useful (on non-"gnu-linux" systems) for specifying what OS partition to mount for automounters, just to name one example. Different OS versions often have different libc versions (for example), so while it may be easy to run a SunOS5 binary on later versions of the OS, it may not be possible to run a SunOS9 binary on earlier versions of the OS. > autoconf was developed 10 years ago when there were dozens of different > Unix variants, and it helped a lot. Now we have dozens of Linux > distributions, and autoconf helps again. Why would you need to check for > SuSE Linux in order to decide whether to install a startup script in > /etc/init.d or /etc/rc.d? Better test whether each of these directory > exists. Then you won't have to change your test the day SuSE Linux is > renamed into Novell Linux (just a hypothetical example). Well, in the old days we used sysIII and sysV in various incarnations to avoid coding a different value for every reseller of those OSes. Simliarly for the different BSD releases. If the releases are all that similar, why not use: i686-GnuLinux-* as your test, and provide the "popular" distributions in the 3rd field? The "magic" command has a large database of selections on it; using this sort of mechanism should greatly ease the burder on the config.* maintainers. config.guess started out life as a useful infrastructure tool, and the arrival of the 4-part format and the generic "gnu-linux" tag renders it quite useless for anything other than configure. A *ton* of people have to work around the current behavior, and there isn't a really useful and easy place to share knowledge about how to determine and test for additional knowledge. Mailing lists just don't do it. Subject threads are problematic, and one often has to plow thru tons of cruft to get to useful nuggets that are often strewn across many messages. Can somebody put up a twiki for auto* macros and addons? H
Re: 1.8 and mkdir_p
> > [1] There are people who think a config.guess output that says: > > > > i686-pc-linux-gnu > > > > is "normal", while some of us feel that is a particularly useless value a= > nd > > would prefer to see something like: > > > > i686-pc-redhat7.3 > > > > instead, just like the original documentation spec'd out. > > > The differences between ALL of the various linux-gnu implementations are > so slight that they are far more suited to feature tests than something > like this. Are you really serious? What is the "domain" of these similarities? - RC files? - packaging mechanism? - automount filesystem selection based on different OS versions? > Libtool, probably the greatest user of config.guess output, manages just > fine to assume "all GNU/Linux is similar enough". autoconf/configure is by no means the only consumer of config.guess output. H
Re: Help Requests
On Tue, 2003-12-09 at 14:32, dc wrote: > AFAIK There's a third possibility : you could setup a dist-hook target > in Makefile.am which allows you to specify completely your dist rule (I > had the same problem than yours and used this method). Unfortunately, it > also means that you might have to update this rule each time you change > metadata in your source tree. Thanks for the response. After a bit of a long holiday break, I am back trying to get this to work. As a quick review, my Makefile.am is not located in the top-level of my directory structure and is causing a problem with make dist. Changing this structure is beyond my control, so I'm stuck with what's there. Therefore, I've tried a number of attempts at writing a dist-hook as suggested above. However, I have again run into problems. When I run make dist, it populates the distdir, but due to the use of manual VPATHs (i.e. ../..), what it actually populates is above the distdir - all that ends up in this directory is the DIST_COMMON stuff. So, my plan is to have the dist-hook delete the mess created by the VPATH stuff, and then copy the necessary files into the distdir manually before it gets tarred up (if there is a better way to approach this, please advise). Here is an example of my attempt: ISRC = $(srcdir)/../../include [snip] dist-hook: rm -rf $(distdir)/$(ISRC) \ mkdir $(distdir)/include \ cp -pR $(ISRC) $(distdir)/include Now, the rm command deletes as expected, but the mkdir and cp don't seem to do anything. As before, I only end up with a tar.gz of the DIST_COMMON files, which are the only files in the distdir. Does anyone have a suggestion on how to proceed, or perhaps someone could point out the flaw in my reasoning? Thanks very much! Best Regards, Scott > /// didier > > Le mar 09/12/2003 Ã 21:19, J. Scott Amort a Ãcrit : > > Thanks for the response! > > > > On Tue, 2003-12-09 at 08:05, Thien-Thi Nguyen wrote: > > > i see from the previous post that you use a "manual VPATH" methodology. > > > there are two approaches you can try: > > > > > > 1/ undo the unorthodoxy (move auto* files to top-level dir) > > > 2/ prefix relative paths (such as "../../") w/ $(srcdir) > > > > I gave #2 a try, and it didn't change the output of make dist. However, > > moving everything into the top-level dir (#1) did solve the problem. > > Unfortunately, I don't currently have any control over the directory > > structure (the motivation behind the attempt is to keep platform > > specific items, i.e. *nix makefiles, VC++ 6 project files, etc. in > > subdirectories away from the source files). I'll speak to the powers > > that be and see about getting this changed. Thanks again.
