automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: config.guess and freedom


From: Ralf Corsepius
Subject: Re: config.guess and freedom
Date: Thu, 08 Jan 2004 17:32:28 +0100

On Thu, 2004-01-08 at 16:42, Gary V. Vaughan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ralf Corsepius wrote:
> | I don't know how libtool applies config.guess and if/how my
> | problems with libtool are connected to config.guess'ing.
> 
> Here is a short (but not atypical) example of the sort of thing libtool needs
> config.guess for:
> 
> case $host_os in
> aix3*)
> ~  # AIX sometimes has problems with the GCC collect2 program.  For some
> ~  # reason, if we set the COLLECT_NAMES environment variable, the problems
> ~  # vanish in a puff of smoke.
> ~  if test "X${COLLECT_NAMES+set}" != Xset; then
> ~    COLLECT_NAMES=
> ~    export COLLECT_NAMES
> ~  fi
> ~  ;;
> esac
> 
> We use it frequently:
> 
> $ fgrep 'case $host' `which libtool` \
> - - /usr/local/share/libtool/m4/*.m4 | wc -l
> ~     71
> 
> | Anyway, my comment was meant generally. I was referring to attempts to
> | apply config.guess'ed valued to configuration tables, e.g. something
> | similar to this:
> | case $host_os in
> | redhat7.3) f=/etc/txt.cfg;;
> | redhat8.0) f=/etc/sysconfig/txt.cfg;;
> | redhat*) f=/etc/foo/txt.cfg;;
> | suse9.0) f=/etc/var/txt.cfg;;
> | solaris*) f=/etc/config/txt.cfg;;
> | ...
> | esac
> 
> Not dissimilar, excepting your emphasis on linux distributions.
Well, this is not related to linux at all. It is a general issue.

Wrt. your example: You are supporting aix3*. Now IBM renames AIX to
something else or changes some fundamental characteristics of their OS
without changing the $host_os.

All you can do is to extend, extend and extend your "case".

Admitted, this is not very realistic with AIX, but it is very likely to
happen with open source OSes, has happened before and will happen again.

Remember the linux switching from libc4->libc5->libc6, from
a.out->coff->elf, the confusion wrt. the linux tuple iterating beween
permutations of  linux-gnu<->linux-(g)libc(5|6|)<->linux-gnu-glibc(5|6|)
etc., the recent solaris*/sunos* dispute and cases where OSes switch
their object format without changing host_os.

Now imagine, a linux vendor deliberately changing the tuple for "their
distro". This would require *all* configure scripts applying
config.guess'ed values to be modified.

Another problematic case is ensuring "correctness" of guess-derived
results. Without additional checks, you can't guarantee anything.
Eg. wrt. host_os, you can't guess on the object format or if an OS
honors LD_LIBRARY_PATH/LD_RUN_PATH or other advanced linker features
libtool might require on a system (I am not a libtool expert, so bare
with the examples).

>   I have no
> strong opinion on the linux-gnu argument,
Neither do I. Fact is "linux-gnu" is standard these days, and can't
easily changed without breaking many existing packages, relying on
config.guess'ed values.

>  but I think your original comment
> devalues config.guess unfairly.
My opinion differs. 

To me, using config.guess'ed values should only be applied as absolute
last resort if all else fail. In any case using them is fragile.

Ralf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]