From: David Huggins-Daines <dhd@linuxcare.com>
To: Bdale Garbee <bdale@gag.com>
Cc: parisc-linux@thepuffingroup.com, debian-parisc@lists.debian.org
Subject: Re: [parisc-linux] Architecture string change
Date: 11 Jul 2000 10:28:21 -0400 [thread overview]
Message-ID: <87k8esbv22.fsf@linuxcare.com> (raw)
In-Reply-To: Bdale Garbee's message of "Mon, 10 Jul 2000 19:55:47 -0600 (MDT)"
Bdale Garbee <bdale@gag.com> writes:
> When I asked about the apparent confusion a while back, I got the very
> strong indication that the parisc-linux community wanted to use 'parisc' for
> the arhitecture string in Debian space... so that's the direction I've been
Well, there's no reason why DEB_HOST_GNU_CPU has to be the same as
DEB_HOST_ARCH. Although I think I've seen a few debian/rules files
(including one of my own at one point) that do things like this:
build:
./configure --host=$(DEB_HOST_ARCH)-linux
Just to make it clear, this discussion is about DEB_HOST_GNU_CPU,
i.e. the CPU part of the string returned by config.guess and accepted
by configure, autoconf, and automake.
> I have no emotional loading on this one, I just want to know the answer. :-)
I'm a bit biased towards 'hppa' just because it is the currently
accepted convention with all the GNU software out there. Also it will
be a bit of a hack to config.guess to return parisc*, because we'll
end up only doing it on Linux. Also, if we go with 'parisc', then:
(a) We need to send patches for config.guess and config.sub to the
automake and autoconf people NOW.
(b) We must be prepared to manually update config.guess and config.sub
in basically every piece of software we build. [1]
> We *must* decide this once and for all *very* soon. Pretty please.
Yup :-)
[1] On Alpha, there continue to be annoying problems when building GNU
software because config.guess (which is part of autoconf) knew about
the PCA56 and EV6 subarchitectures long before config.sub (which is
part of automake) did, and thus configuring would always fail unless
--host=alpha-linux (or some other recognizable architecture string)
was specified. Because the maintainer has to manually update
config.guess and config.sub, lots of packages still have old versions
that break...
--
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
next prev parent reply other threads:[~2000-07-11 14:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-10 21:45 [parisc-linux] Architecture string change David Huggins-Daines
2000-07-10 22:59 ` Grant Grundler
2000-07-10 23:04 ` John David Anglin
2000-07-11 1:55 ` Bdale Garbee
2000-07-11 14:28 ` David Huggins-Daines [this message]
2000-07-11 18:15 ` Andrew Shugg
2000-07-11 18:36 ` John David Anglin
2000-07-11 10:18 ` Corne Beerse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k8esbv22.fsf@linuxcare.com \
--to=dhd@linuxcare.com \
--cc=bdale@gag.com \
--cc=debian-parisc@lists.debian.org \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox