cmucl-19e + gcc43 better, not quite there

Tried out cmucl-19e-pre1, and this works better (than
cmucl-19d) and
gets further, but fails in some asm in
../../src/lisp/x86-assem.S
../../src/lisp/x86-assem.S: Assembler messages:
../../src/lisp/x86-assem.S:84: Error: suffix or operands
invalid for
`fnstsw'

??

For complete build.log, see
http://koji.fedoraproject.org/koji/ge
tfile?taskID=515618&name=build.log

Further, attached is a quick-n-dirty patch I needed to make
it not choke on
#include <sys/syscalls.h>
->
#include <asm/unistd.h>
which contains
#ifdef __i386__
#include "unistd_32.h"
#else
#include "unistd_64.h"
#endif
on recent kernel-headers.  In short, translating -I- to use
-iquote instead
(and have the build respect our rpm optflags)

-- Rex



-- Binary/unsupported file stripped by Listar --
-- Type: text/x-patch
-- File: cmucl-19e-optflags.patch

Rex Dieter wrote:

> Further, attached is a quick-n-dirty patch I needed to
make it not choke on
> #include <sys/syscalls.h>
...
> -- Binary/unsupported file stripped by Listar --

Arg, how about this then,
http://cvs.fedorapro
ject.org/viewcvs/*checkout*/devel/cmucl/cmucl-19e-optflags.p
atch?rev=1.1

-- Rex

Hi Rex,

On Fri, Mar 14, 2008 at 12:37 PM, Rex Dieter <rdietermath.unl.edu> wrote:
> Tried out cmucl-19e-pre1, and this works better (than
cmucl-19d) and
> gets further, but fails in some asm in
> ../../src/lisp/x86-assem.S
> ../../src/lisp/x86-assem.S: Assembler messages:
> ../../src/lisp/x86-assem.S:84: Error: suffix or
operands invalid for
> `fnstsw'

Can you change that line to "fnstsw %ax" and
running the compile again?

> Further, attached is a quick-n-dirty patch I needed to
make it not choke on
> #include <sys/syscalls.h>
> ->
> #include <asm/unistd.h>
> which contains
> #ifdef __i386__
> #include "unistd_32.h"
> #else
> #include "unistd_64.h"
> #endif
> on recent kernel-headers.  In short, translating -I- to
use -iquote instead
> (and have the build respect our rpm optflags)

I committed a change to the FreeBSD and Darwin configuration
files
which switch to using -iquote when the compiler is not GCC 2
or 3.  I
can make a change to the Linux configuration file as well. 
However, I
do not understand how this problem relates to the kernel
header files.
 Is the underlying problem that the wrong header file is
being found
when an -iquote is not used?

Carl

Carl Shapiro wrote:

> Hi Rex,
> 
> On Fri, Mar 14, 2008 at 12:37 PM, Rex Dieter
<rdietermath.unl.edu> wrote:
>> Tried out cmucl-19e-pre1, and this works better
(than cmucl-19d) and
>> gets further, but fails in some asm in
>> ../../src/lisp/x86-assem.S
>> ../../src/lisp/x86-assem.S: Assembler messages:
>> ../../src/lisp/x86-assem.S:84: Error: suffix or
operands invalid for
>> `fnstsw'
> 
> Can you change that line to "fnstsw %ax" and
running the compile again?

Yes, that seemed to help.  Now I'm seeing some bits not
building (but it's
better)
http://koji.fedoraproject.org/koji/ge
tfile?taskID=517448&name=build.log
excerpt:
install: cannot stat
`i386-redhat-linux-gnu-4/hemlock/hemlock-library.x86f':
No such file or directory
install: cannot stat
`i386-redhat-linux-gnu-4/hemlock/spell-dictionary.bin':
No such file or directory
install: cannot stat
`i386-redhat-linux-gnu-4/interface/clm-library.x86f':
No such file or directory
install: cannot stat
`i386-redhat-linux-gnu-4/motif/server/motifd': No such
file or directory

I'll keep digging.

>> Further, attached is a quick-n-dirty patch I needed
to make it not choke
>> on
>> #include <sys/syscalls.h>
>> ->
>> #include <asm/unistd.h>
>> which contains
>> #ifdef __i386__
>> #include "unistd_32.h"
>> #else
>> #include "unistd_64.h"
>> #endif
>> on recent kernel-headers.  In short, translating
-I- to use -iquote
>> instead (and have the build respect our rpm
optflags)
> 
> I committed a change to the FreeBSD and Darwin
configuration files
> which switch to using -iquote when the compiler is not
GCC 2 or 3.  I
> can make a change to the Linux configuration file as
well.  However, I
> do not understand how this problem relates to the
kernel header files.
>  Is the underlying problem that the wrong header file
is being found
> when an -iquote is not used?

Else, get "unistd_32.h" not found errors.

-- Rex

On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter <rdietermath.unl.edu> wrote:
>  Yes, that seemed to help.  Now I'm seeing some bits
not building (but it's
>  better)

Great!

It looks like your build is failing look for the following
output

"target:clx/clx-library.x86f" out of date.
interrupt_handle_now: No handler for signal 1486158303?
LDB monitor
ldb>

Is there any chance that some stale object code is in your
build directory?

>  Else, get "unistd_32.h" not found errors.

OK.  So, will the problem be solved if we start using
-iquote in the
Linux build files?

Carl Shapiro wrote:
> On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter
<rdietermath.unl.edu> wrote:
>>  Yes, that seemed to help.  Now I'm seeing some
bits not building (but it's
>>  better)
> 
> Great!
> 
> It looks like your build is failing look for the
following output
> 
> "target:clx/clx-library.x86f" out of date.
> interrupt_handle_now: No handler for signal
1486158303?
> LDB monitor
> ldb>
> 
> Is there any chance that some stale object code is in
your build directory?

Unlikely, I'm using clean/minimal chroot for each build.   
The failure 
is occurring trying to build for fedira9 (development) that
uses gcc43. 
  Fwiw, this same build works fine on fedora8 (using
gcc41).

/me keeps digging.

>>  Else, get "unistd_32.h" not found
errors.
> 
> OK.  So, will the problem be solved if we start using
-iquote in the
> Linux build files?

Yes, I can confirm that using -iquote solves this particular
problem.

-- Rex

On Sat, Mar 15, 2008 at 6:11 AM, Rex Dieter <rdietermath.unl.edu> wrote:
>  Unlikely, I'm using clean/minimal chroot for each
build.    The failure
>  is occurring trying to build for fedira9 (development)
that uses gcc43.
>   Fwiw, this same build works fine on fedora8 (using
gcc41).

Is there an easy way I can reproduce your build environment
locally?

In the mean time, I will check-in the -iquote and assembly
code changes.

Carl Shapiro wrote:
> On Sat, Mar 15, 2008 at 6:11 AM, Rex Dieter
<rdietermath.unl.edu> wrote:
>>  Unlikely, I'm using clean/minimal chroot for each
build.    The failure
>>  is occurring trying to build for fedira9
(development) that uses gcc43.
>>   Fwiw, this same build works fine on fedora8
(using gcc41).
> 
> Is there an easy way I can reproduce your build
environment locally?

I would be tempted to say "on any gcc43-derived linux
system", but I'm 
not convinced that gcc43 is the (sole, if at all) culprit.

In the meantime, I'll see about whipping up a hosted
fedora-9-i386 VM, 
to help debugging. (I personally only have a single
f9/x86_64 box atm). 
  I will give access to any cmucl dev's wiling to help out
here.

-- Rex

Carl Shapiro wrote:
> On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter
<rdietermath.unl.edu> wrote:
>   
>>  Yes, that seemed to help.  Now I'm seeing some
bits not building (but it's
>>  better)
>>     
>
> Great!
>
> It looks like your build is failing look for the
following output
>
> "target:clx/clx-library.x86f" out of date.
> interrupt_handle_now: No handler for signal
1486158303?
>   
FWIW, it appears that run-program is broken.

(run-program "/bin/cat" '("/etc/issue")
:output "/tmp/foo")

causes a segv at address 0.  Not sure why yet, but it
explains why I see 
the segvs after cmucl prints out messages that
foo-library.x86f is out 
of date.

Ray

On Mon, Mar 24, 2008 at 6:52 PM, Raymond Toy
<toy.raymondgmail.com> wrote:
>  (run-program "/bin/cat"
'("/etc/issue") :output "/tmp/foo")
>
>  causes a segv at address 0.  Not sure why yet, but it
explains why I see
>  the segvs after cmucl prints out messages that
foo-library.x86f is out
>  of date.

I take it that run-program never returns?  Does this happen
on your
SuSE machine or some other Linux?  I cannot reproduce this
on my
Ubuntu machine using the latest snapshot.