Mail Archives: djgpp/2011/01/29/09:02:38
Am Donnerstag, 20. Januar 2011 schrieb Eli Zaretskii:
> > From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> > Date: Wed, 19 Jan 2011 19:25:46 +0100
> > Cc: djgpp AT delorie DOT com
> >
> > > How come the v2.03 build avoided this issue?
> >
> >
> > config.sub produces for an input string that contains "djgpp" the hardcoded
> > output string "i586-pc-msdosdjgpp". config.guess uses uname to detect the
> > processer type. This script concatenates the output produced by "uname -m"
> > together with the string "pc-msdosdjgpp". The 2.04 version of uname returns
> > "i786" but the 2.03 version of uname returns "i586". In those cases we get for
> > the 2.04 version: i786-pc-msdosdjgpp and for
> > the 2.03 version: i586-pc-msdosdjgpp.
>
> Can you suggest a change in config.sub that would accommodate both
> v2.03 and v2.04? If so, please submit that change to config.sub
> maintainers.
>
> Thanks.
I was wrong config.[sub|guess] work as designed. The question remains if the
design is good for DJGPP. The real bug is the DJGPP 2.03 port of uname. This
program does not behave as it would be necessary to be usefull when used with
config.[guess|sub].
config.guess uses uname to create a system ID string of the form CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
e.g.: i786-pc-msdosdjgpp. To be able to create such a string uname -m must
return a usefull information. The 2.04 port of uname returns i786 but the
2.03 port of uname returns pc. This is recognized by config.guess and the
DJGPP specific hardcoded string of i586-pc-msdosdjgpp is returned. This means
that any DJGPP specific argument to config.guess that does not match the
canonical form generates i586-pc-msdosdjgpp output string.
config.sub expects as argument a string of the form CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM.
If the argument matches the canonical form then the output string is identical
to the argument. For the DEJGPP case, if the argument does not match the
canonical form then the hardcoded string i586-pc-msdosdjgpp is returned.
All this means that config.[sub|guess] have been coded completely DJGPP 2.03
centric and they will very likely fail with other DJGPP ports of uname.
The reason why the build fails when DJGPP 2.04 is used is due the code copied
into the Makefile template contained into /config/mh-djgpp. This is the
offending part:
# Shorten the target alias so when it is used to set 'libsubdir'
# the name will work in both short and long filename environments.
ifeq ($(findstring -pc-msdosdjgpp,$(target_alias)),-pc-msdosdjgpp)
target_alias=djgpp
endif
When gdb is configured by running the toplevel configure script, this script
cleanly identifies or the DJGPP 2.03 host/target system or the DJGPP 2.04
host/target system. config.[guess|sub] work in both cases as they should work.
For DJGPP 2.03 the Makefile head contains the following lines:
# -------------------------------
# Standard Autoconf-set variables
# -------------------------------
VPATH=..
build_alias=i586-pc-msdosdjgpp
build_vendor=pc
build_os=msdosdjgpp
build=i586-pc-msdosdjgpp
host_alias=i586-pc-msdosdjgpp
host_vendor=pc
host_os=msdosdjgpp
host=i586-pc-msdosdjgpp
target_alias=i586-pc-msdosdjgpp
target_vendor=pc
target_os=msdosdjgpp
target=i586-pc-msdosdjgpp
For DJGPP 2.04 the Makefile head contains the following lines:
# -------------------------------
# Standard Autoconf-set variables
# -------------------------------
VPATH=..
build_alias=i786-pc-msdosdjgpp
build_vendor=pc
build_os=msdosdjgpp
build=i786-pc-msdosdjgpp
host_alias=i786-pc-msdosdjgpp
host_vendor=pc
host_os=msdosdjgpp
host=i786-pc-msdosdjgpp
target_alias=i786-pc-msdosdjgpp
target_vendor=pc
target_os=msdosdjgpp
target=i786-pc-msdosdjgpp
As can be seen in both cases everthing is OK because build_alias = host_alias = target_alias.
This means that a native debugger should be compiled. Unfortunately the mh-djgpp
file changes the target_alias to djgpp. This value is passed to the configure
scripts of the different directories and they pass "djgpp" as argument to
config.sub. config.sub returns as target_alias always i586-pc-msdosdjgpp
if its input argument was "djgpp". This always works for DJGPP 2.03 because it
matches the output produced by config.guess with uname version produced with
DJGPP 2.03; but it fails for any other DJGPP version of uname.
Although my initial assumption that config[guess|sub] were brocken was wrong,
the patch I have applied to config.sub DTRT. Neitherless probably the rigth
place to fix this is the /config/mh-djgpp file. That file is very old and I
think it should be adapted by the author.
OFYI, below the small patch to config.sub, to get it working with all versions
of uname.
Regards,
Juan M. Guerrero
diff -aprNU5 gdb-7.2.orig/config.sub gdb-7.2/config.sub
--- gdb-7.2.orig/config.sub 2010-06-01 17:53:40 +0000
+++ gdb-7.2/config.sub 2011-01-22 23:28:54 +0000
@@ -579,11 +579,19 @@ case $basic_machine in
dicos)
basic_machine=i686-pc
os=-dicos
;;
djgpp)
- basic_machine=i586-pc
+ UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
+ case $UNAME_MACHINE in
+ *386*) basic_machine=i386-pc;;
+ *486*) basic_machine=i486-pc;;
+ *586*) basic_machine=i586-pc;;
+ *686*) basic_machine=i686-pc;;
+ *786*) basic_machine=i786-pc;;
+ *) basic_machine=i586-pc;;
+ esac
os=-msdosdjgpp
;;
dpx20 | dpx20-*)
basic_machine=rs6000-bull
os=-bosx
- Raw text -