Re: Bug#39227: apt: archtable does not support hurd
On Wed, Jun 09, 1999 at 05:09:27PM -0600, Jason Gunthorpe wrote:
>
> On Wed, 9 Jun 1999 brinkmd@debian.org wrote:
>
> > the "gcc --print-libgcc-file-name" + archtable trick obviously doesn't work
> > on the Hurd without changes.
>
> Why shouldn't it? What does --print-libgcc-file-name return on the hurd?
Well, it produces a sane string (exactly what you'd expect), but all existing
conversion rules by Debian ignore the difference between "linux" and "gnu".
Nothing too serious.
> > I suggest to try:
> >
> > "dpkg --print-installation-architecture" if not cross-compiling and dpkg
> > is available, which should always be correct, and is the only sensible
> > way without duplicating "arbitray" conversion code from dpkg.
>
> There are two things being set here, the first is the arch string for dpkg
> and the next is the byte sizes for the MD5 code, it is important to not
> munge up either.
Okay, I see. But why do you hardcode the sizes in buildlib/sizetable even
in the default case (eg not cross compiling)? Can't the autoconf test not be
trusted? I would suggest to access sizetable only when cross_compiling is
"yes", and use the autoconf tests in all other cases.
Thinking about it, I would even suggest to drop sizetable and let the user
specify a configure cache with those values (every person cross compiling
has a configure cache with those values handy, there are even correct ones
in dpkg-cross package, and dpkg-cross knows how to activate them).
Hardcoding those values when they can be determined at run time seems to be
dangerous at least.
> > For cross compilation, the gcc trick is a good approximation, but please
> > don't strip off -whatever, but check if it is linux or gnu, or even better,
> > use full gnu system type names in the archtable:
> >
> > i386-linux i386 i486
> > i386-gnu hurd-i386 i486
>
> What you really need here is a seperate setting that indicates what the OS
> is, it would be nicer than trying to munge the arch string. What could be
> done is to write a detection rule for hurd/linux/etc and have that create
> a sepeare entry in config.h, it could then munge it internally to generate
> the correct test for whatever todays arch/system standard is.
I am not sure I understand you correctly. We have the following conditions:
Debian architecture: i386
host_cpu=i386
host_os=linux-gnu
Debian architecture: alpha
host_cpu=alpha
host_os=linux-gnu
etc.
Debian architecture: hurd-i386
host__cpu=i386
host_os=gnu
Note that "Debian architecture" is an _arbitrary_ string that is only
connected to "host_cpu" because people wanted it this way. Now that we have
Debian architecture names like "hurd-i386", we have to be more careful not
confuse the Debian arhcitecture name with the name of a CPU or OS.
There is no unique mapping from the values of host_cpu to the Debian
architecture name ("i386" and "hurd-i386" have both "i386" as host_cpu), so
it makes sense to me to use the unique $host_cpu-$host_os.
Do you still think the file buildlib/archtable shouldn't contain full GNU
type names and map them to Debian architecture names?
> I like having the arch transforms as a seperate operation from system type
> transforms, that seems to make more sense.
I can see why this is useful for the sizes of the int types, but what you
are overlooking here is that configure already makes a detailed analyse of
the system type. It gives you the CPU and OS in different variables. To be
more specific, what I suggest would be to change archtable:
dnl Converts the ARCH to be the same as dpkg
AC_MSG_CHECKING(system architecture)
archset="`awk '$1 == "'$host_cpu'" { print $2 }' $srcdir/buildlib/archtable`"
^^^^^^^^^
I would use ${host_cpu}-${host_os} here and extend archtable.
if test "x$archset" = "x"; then
AC_MSG_ERROR(failed: use --host=)
fi
AC_MSG_RESULT($archset)
AC_DEFINE_UNQUOTED(ARCHITECTURE,"$archset")
> > BTW, can pthreads be made optional? It seems apt-get can be build without
> > pthread, and it would be good for configure just to disable components that
> > require pthread instead of bailing out completely (reason is that the Hurd
> > does not have pthreads implemented of course. We wouldn't miss the fancy
> > gui right now, but we miss the apt-get tool a lot).
>
> Yes, that test could be removed from configure. As long as the C library
> does not declare it has pthread support by defing _POSIX_THREADS then
> everything will be OK. The GUI library does/did/might require pthreads but
> that isn't compiled by default anymore
Okay, sounds great.
> I'm not terribly good with hacking configure/autoconf, if you could
> implement a good patch for the system type that would be very nice. Sounds
> like all that is needed is to save the -foo part after the arch string and
> write that to the config file.
I will send you a patch, no problem. However, my first try would follow the
analyse above. If you do not agree, we have to discuss this further.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: