www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/02/25/09:01:36

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
From: Tim Van Holder <notme AT spamproofemail DOT com>
Subject: Re: Which cxxfilt.exe? Which config.site?
Date: Mon, 25 Feb 2002 14:01:11 +0100
Newsgroups: comp.os.msdos.djgpp
Message-ID: <pan.2002.02.25.14.01.08.408884.22072@spamproofemail.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020221091141 DOT 3007A-100000 AT is> <3c74fec8 DOT 1409243 AT news DOT earthlink DOT net>
User-Agent: Pan/0.11.2 (Unix)
Mime-Version: 1.0
X-Comment-To: "Peter J. Farley III" <pjfarley3 AT earthlink DOT net>
Lines: 59
Organization: -= Skynet Usenet Service =-
NNTP-Posting-Host: 194.78.64.238
X-Trace: 1014642143 reader1.news.skynet.be 33506 194.78.64.238
X-Complaints-To: abuse AT skynet DOT be
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

In a burst of inspiration, "Peter J. Farley III" <pjfarley3 AT earthlink DOT net>
wrote this on Thu, 21 Feb 2002 15:21:23 +0100:

> They are radically different, with only a couple of common entries. In
> the case of the PATH variable set by the config.site from acnf250b.zip,
> if PATH already contains (for example) "c:/djgpp/bin", it creates
> functionally duplicate entries in the PATH, and it could make the PATH
> exceed it's maximum length, causing more problems than it solves.

The reason /dev/env/DJDIR/bin is prepended is to cause configure to find
DJGPP exutables with that path, so that
 -) config.cache files are more portable across DJGPP environments
 -) applications that hardcode such a path at compile time will still
    work on systems with a different DJDIR

I suppose I could do a hairier transform of PATH (replacing $DJDIR/bin
with the /dev/env path if present), but I'm not sure it's worth it.

> However, what I'm mainly wondering is whether those "ac_cv_func_..."
> entries in the copy from acnf250b are truly needed when running
> /configure scripts.

They are mostly useful for packages that haven't been ported to DOSish
systems yet.  They'll test for fork() and use it, which results in
breakages on DOSish platforms.  We have a fork() function, but not a
working one; using the ac_cv_* vars makes autoconf think this has
already been tested for (and not found).

> Perhaps Tim and Mark E. should get together on this and come up with a
> consolidated version.

The problem is this: autoconf and bash evolve at a different pace.
Users should not need to install autoconf just to run configure scripts,
so config.site is included with bash.  But newer versions of autoconf
may need additional/fewer entries in config.site.  Since it's
unreasonable to require a new bash package every time this happens,
config.site is also included in the autoconf package.
I'll post newer versions of config.site to djgpp-workers for review
before I build an autoconf package.

> Advice appreciated.

I'm currently using a config.site that detects the autoconf version used
to create the configures script being run, and sets variables
accordingly (based on the config.site that comes with bash 2.05).  This
will also be included in the DJGPP package for autoconf 2.53 (when it's
released).  I'll try to remember to post it in this thread tonight.

> # The root of the DJGPP tree serves as the default prefix. # Allow for
> cases where a top-level Cygnus/Red Hat-style configure script # calls
> Autoconf configure scripts in subdirectories. if test
> "x$ac_default_prefix" = "x/usr/local"; then
> ac_default_prefix="/dev/env/DJDIR"
> fi

I don't do this anymore; and I'm still in doubt over whether I should
have DJGPP's autoconf default to DJDIR as prefix.
Using --prefix seems cleaner (and is the 'normal' way of pulling in a
system-wide config.site, instead of using $CONFIG_SITE).

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019