Re: gcc-2.95.2 or linux86-0.14.9 problem (maybe)

[Stephan A Suerken <inf222@Fh-Worms.DE>]

Joop Stakenborg <aba@casema.net> writes:

> > /tmp/ccAizL65.s:5173: Warning: using `%ax' instead of `%eax' due to `w' suffix
> > make[1]: *** No rule to make target `cpustbl.o', needed by `uae'.  Stop.
> > make[1]: Leaving directory `/mnt/orlok/home/absurd/lib/absurd/code/script/debian/uae/0.7.6/uae-0.7.6/src'
> > make: *** [all] Error 2
> > ---
> > 
> > Maybe someone can 1st of all point me to what the assembler warnings
> > mean...
> >
> 
> They are only warnings. They don let yout compile fail.

Sure. At least, most of the times...

> There is not target for cpustbl.o. Have a closer look at your makefile.
> I guess make became more critical when going from slink to potato.

Checked this; new potato make is some difference (see below), but it's
not the problem.

Wichert Akkerman <wichert@liacs.nl> writes:

> Previously Joop Stakenborg wrote:
> > There is not target for cpustbl.o. Have a closer look at your makefile.
> > I guess make became more critical when going from slink to potato.
> 
> Probably not. An old dependency is a more likely problem.

 If you mean some side effect due to stale files (in .deps or
elsewhere), I have excluded this possibility by running my tests on
the freshly xtracted .orig sources.

 As it didn't seem to be a commonly known error, I did some more tests
of my own. I am reasonably sure that the problem is the assembler code
of the upstream, which only work together with old [g]as from binutils
<=2.9.4.0.3-0.1. (read: 2.9.4.0.3-0.1 was the last version working).

 Supposed I am right, there's obviously no other solution but patching
(maybe all) the assembler code of the upstream, which I won't do. So
my strategy is to file a bug report against uae and forward it
upstream. I have not found a hint/patch/whatever on the uae home page
about this.

 And, supposed I am right, I wonder if there are more packages not
compiling due to the new as...

 My reasoning is appended; it's rather a log for myself of the
(usable) tests I did. If someone disagrees with my deduction or sees
some silly mistakes (tm) please tell me, but there is no real need to
read the rest of this mail.

Thanks,

Stephan

---
o Check if old make is a difference

Compile test: potato && slink make:

gcc -I. -I../src/include/ -c  -O2 -fomit-frame-pointer  -Wall -Wno-unused -Wno-format -W -Wmissing-prototypes -Wstrict-prototypes   -DUSING_GTK_GUI -DGCCCONSTFUNC="__attribute__((const))" -DSUPPORT_THREADS -D_REENTRANT -fno-exceptions -DX86_ASSEMBLY -DUNALIGNED_PROFITABLE -fno-strength-reduce -DREGPARAM="__attribute__((regparm(3)))" -DHAVE_GLIBC_2_LINUX -DUSE_ZFILE -D__inline__=inline  -DSTATFS_NO_ARGS=2 -DSTATBUF_BAVAIL=f_bavail  -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/lib/glib/include -DSHM_SUPPORT_LINKS=1  machdep/X86.S -o machdep/X86.o
/tmp/ccWXFNkw.s: Assembler messages:
/tmp/ccWXFNkw.s:173: Error: suffix or operands invalid for `call'
/tmp/ccWXFNkw.s:534: Error: suffix or operands invalid for `call'
/tmp/ccWXFNkw.s:934: Warning: using `%dx' instead of `%edx' due to `w' suffix
make[1]: *** [machdep/X86.o] Error 1
make[1]: Leaving directory `/tmp/uae-0.7.6.orig/src'
make: *** [all] Error 2
=============
Ok, this actually fails with an assembler error. I found out that for
a normal potato compile, the same error would appear if I simply run a
new instance of make (this actually builds cpustbl.o, and then fails
with the same above assembler errors, which is a little bit
strange...).

Checking the upstream NEWS for gas from binutils I found:

Greatly improved instruction operand checking for i386.  This change will
produce errors or warnings on incorrect assembly code that previous versions of
gas accepted.  If you get unexpected messages from code that worked with older
versions of gas, please double check the code before reporting a bug.
======
Trying to find a fix...

Checking as.1, there does not seem to be a way to make these errors
non-fatal. Just for a test (usable if positive), I downgraded to slink
binutils; make fails with "Error: no such 386 instruction: `filds'"
when building fpp.o. However, downgrading to slink programs is not a
good idea (tm).

Decided not to do further tests...

-- 
s-Stephan A Suerken <inf222@fh-worms.de>
s-Voice (+49) (6241) 92566-2 -- WWW http://www.fh-worms.de/~inf222
s-Debian-related mail: <absurd@debian.org>