headers
Raymond Toy (RT/EUS | 14 Mar 2008 20:18
Picon
Favicon

Re: cmucl-19e + gcc43 better, almost there

Rex Dieter wrote:
> Anyone else trying cmucl-19e on a gcc43-based system?  Any tips, tricks?

Hey, your mail finally made it! :-)

> on recent kernel-headers.  In short, translating -I- to use -iquote 
> instead (and have the build respect our rpm optflags)

Can you describe why you want or need those other optflags?  (I'm not 
familiar with them.)

Ray
Permalink | Reply | 1 comment |
headers
Rex Dieter | 14 Mar 2008 20:37
Favicon
Gravatar

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/getfile?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
(Continue reading)

Permalink | Reply | 19 comments |
headers
Rex Dieter | 14 Mar 2008 20:50
Favicon
Gravatar

Re: cmucl-19e + gcc43 better, almost there

Raymond Toy (RT/EUS) wrote:

>> on recent kernel-headers.  In short, translating -I- to use -iquote 
>> instead (and have the build respect our rpm optflags)
> 
> Can you describe why you want or need those other optflags?  (I'm not 
> familiar with them.)

The latter part about using rpm optflags almost certainly is not of
interest for upstream inclusion.  The switch away from -I- *is*.

Using rpm optflags is mostly for distro consistency, and for us/fedora
anyway, ensures a higher level of distro-wide security, including:
-Wp,-D_FORTIFY_SOURCE=2 and -fstack-protector

-- Rex
Permalink | Reply | 0 comments |
headers
Rex Dieter | 14 Mar 2008 20:52
Favicon
Gravatar

Re: cmucl-19e + gcc43 better, not quite there

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.fedoraproject.org/viewcvs/*checkout*/devel/cmucl/cmucl-19e-optflags.patch?rev=1.1

-- Rex
Permalink | Reply | 0 comments |
headers
Carl Shapiro | 14 Mar 2008 22:42
Picon

Re: cmucl-19e + gcc43 better, not quite there

Hi Rex,

On Fri, Mar 14, 2008 at 12:37 PM, Rex Dieter <rdieter <at> math.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
(Continue reading)

Permalink | Reply | 17 comments |
headers
Rex Dieter | 15 Mar 2008 03:00
Favicon
Gravatar

Re: cmucl-19e + gcc43 better, not quite there

Carl Shapiro wrote:

> Hi Rex,
> 
> On Fri, Mar 14, 2008 at 12:37 PM, Rex Dieter <rdieter <at> math.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/getfile?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
(Continue reading)

Permalink | Reply | 16 comments |
headers
Carl Shapiro | 15 Mar 2008 07:31
Picon

Re: cmucl-19e + gcc43 better, not quite there

On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter <rdieter <at> math.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?
Permalink | Reply | 15 comments |
headers
Rex Dieter | 15 Mar 2008 14:11
Favicon
Gravatar

Re: cmucl-19e + gcc43 better, not quite there

Carl Shapiro wrote:
> On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter <rdieter <at> math.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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Carl Shapiro | 15 Mar 2008 22:39
Picon

Re: cmucl-19e + gcc43 better, not quite there

On Sat, Mar 15, 2008 at 6:11 AM, Rex Dieter <rdieter <at> math.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.
Permalink | Reply | 7 comments |
headers
Rex Dieter | 16 Mar 2008 02:58
Favicon
Gravatar

Re: cmucl-19e + gcc43 better, not quite there

Carl Shapiro wrote:
> On Sat, Mar 15, 2008 at 6:11 AM, Rex Dieter <rdieter <at> math.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
Permalink | Reply | 6 comments |

Gmane