Master for move-if-change?
Is Autoconf the master project these days for the move-if-change script? Thanks, Ben signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
while configuring bash
Hi, I was running ./configure for bash-3.0 and got this: checking sys/ptem.h usability... no checking sys/ptem.h presence... yes configure: WARNING: sys/ptem.h: present but cannot be compiled configure: WARNING: sys/ptem.h: check for missing prerequisite headers? configure: WARNING: sys/ptem.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for sys/ptem.h... yes checking sys/pte.h usability... no It asked to be reported so here you are... -- groet, David
Re: Master for move-if-change?
Ben Elliston [EMAIL PROTECTED] writes: Is Autoconf the master project these days for the move-if-change script? Yes, as far as I know. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: checking for Berkley db 4.2 -- 4.3 upgrade
On Tue, 19 Jul 2005, Stepan Kasal wrote: Well, instead of a conclusion I have to ask: is Berkeley db functionality available only from one project, or are there several implementations? (I think the db _format_ can be accessed by several independent libraries, but that's not the question.) If you're talking Berkeley DB 2.0 or later, there is only one. The difference in functionality between the old Berkeley DB and the current product by Sleepycat is very substantial at this point, and refering to the various DBM-type libraries as being in the same category as Sleepycat's product is just untrue at this point (they've added transactions, locking, memory pools, replication, all kinds of stuff). That said, as an experienced BDB user, I can say with some certainty that it is quite safe to check for just the version number of any of Sleepycat's products if you're looking for features or behaviors. If you're dealing with the old DBM-type format (Berkeley DB 1.8x), you may be better off probing for features and behaviors; I suspect there are multiple implementations of this type of database. - D ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Behaviour differs at configure time
Hello, All! I have these lines in my configure.ac: AC_CHECK_LIB( pthread, [pthread_create] ) AC_CHECK_HEADERS( pthread.h, [ AC_DEFINE(THREAD_SAFE, 1, [We will use posix threads]) ] ) AC_CHECK_FUNCS( pthread_yield pthread_mutexattr_settype ) I am cross-compiling (--host=arm-linux). When I run the configure script it checks for pthread_mutexattr_settype and finds it. But when I do a make, I get an error saying that this function is not defined. Well, the function is protected by a #ifdef __USE_UNIX98. I guess this is the source of my problem. Why would that be defined during configure and not during make? I don't have any environment vars set that would affect this, I belive. I did this: set | grep FLAG and got nothing. I run configure like this: ~/project/configure --prefix=~/usr --disable-static 'CXXFLAGS=-O3 -g0 -Wall -pedantic-errors -Wno-long-long -Woverloaded-virtual' Thank you, Andre Caldas. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: checking for Berkley db 4.2 -- 4.3 upgrade
On Tue, 2005-07-19 at 20:07 +0200, Stepan Kasal wrote: Hi, On Thu, Jul 14, 2005 at 12:19:26PM -0400, Sam Steingold wrote: * David Boreham [EMAIL PROTECTED] [2005-07-14 08:42:46 -0700]: Wouldn't it be easier to simply read the version number ? ... isn't the whole idea of autoconf to avoid relying on version numbers? no, it isn't, thought it might sound so. Yes, you hear test for features, not for version numbers. The reasoning is like this: Say that you observe a bug in latest Fumix 7.1, which needs a workaround. If you activate the workaround for Fumix = 7.1, you might loose in several cases: 1) if Fumix 7.2 will fix the bug 2) if you encounter a patched version of Fumix 7.1 which no longer has the bug 3) if Fumiris 2.0 will have the same bug So if we speak about a general feature, it's better to test for the feature then to collect version intervals. But if you want to use a function from a particular project, it's more safe to use version numbers: ad 1) Future versions will probably still have the funtion. ad 2) Older versions don't have it. ad 3) If another project provides the same functionality, your build scripts wouldn't be able to use it. I strongly disagree on this - All version checks are unreliable and should remain the absolute last resort if all else fail. Rationale: version checks can only work if all existing shipped binaries of a package provide identical functionality, i.e. if a package doesn't have optional features nor has patches applied. This almost never is the case in any OpenSource project. Example: KDE's gcc-4.0.0 blacklisting. KDE tripped a bug in gcc-4.0.0 which affects a lot of KDE stuff, so they wanted to be clever and blacklisting gcc-4.0.0. They missed that almost all vendor-supplied gccs are patched, so whatever version number a particular gcc might return on a system, has no actual connection to whether this gcc is affected by the bug KDE found worth blacklisting gcc for or not. Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
