Build failure on master

Build failure on master

[Mike Gran]

I'm finding that master fails to build with the following terminating
error:

---

GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
"ice-9/lineio.go" "ice-9/lineio.scm"
ERROR: In procedure make_objcode_by_mmap:
ERROR: bad header on object file: "GOOF-0.5"
make[2]: *** [ice-9/lineio.go] Error 1
make[2]: Leaving directory `/home/mike/Documents/guile/module'

---

Re: Build failure on master

[Ludovic Courtès]

Hi Mike,

Mike Gran <spk121@yahoo.com> writes:

> ERROR: In procedure make_objcode_by_mmap:
> ERROR: bad header on object file: "GOOF-0.5"

Make sure to remove all `.go' files from your source tree and from the
cache (either `~/.guile-ccache' or `~/.cache/guile/ccache').  Then
hopefully you'll be able to compile Guile.

Thanks,
Ludo'.

Re: Build failure on master

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Mike,
>
> Mike Gran <spk121@yahoo.com> writes:
>
>> ERROR: In procedure make_objcode_by_mmap:
>> ERROR: bad header on object file: "GOOF-0.5"
>
> Make sure to remove all `.go' files from your source tree and from the
> cache (either `~/.guile-ccache' or `~/.cache/guile/ccache').  Then
> hopefully you'll be able to compile Guile.

Surely the point of having a version number on the object file format
would be to actually take notice of it, and to change the number when
we make format changes...?

(I'm assuming that this problem was caused by a format change...)

Regards,
        Neil

Re: Build failure on master

[Ludovic Courtès]

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mike,
>>
>> Mike Gran <spk121@yahoo.com> writes:
>>
>>> ERROR: In procedure make_objcode_by_mmap:
>>> ERROR: bad header on object file: "GOOF-0.5"
>>
>> Make sure to remove all `.go' files from your source tree and from the
>> cache (either `~/.guile-ccache' or `~/.cache/guile/ccache').  Then
>> hopefully you'll be able to compile Guile.
>
> Surely the point of having a version number on the object file format
> would be to actually take notice of it, and to change the number when
> we make format changes...?
>
> (I'm assuming that this problem was caused by a format change...)

Yes.

Currently, the code just checks for the magic cookie (see
`make_objcode_by_mmap ()'), and if it differs, e.g., because the version
isn't right, it just bails out.

Eventually, 

Re: Build failure on master

[Ludovic Courtès]

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mike,
>>
>> Mike Gran <spk121@yahoo.com> writes:
>>
>>> ERROR: In procedure make_objcode_by_mmap:
>>> ERROR: bad header on object file: "GOOF-0.5"
>>
>> Make sure to remove all `.go' files from your source tree and from the
>> cache (either `~/.guile-ccache' or `~/.cache/guile/ccache').  Then
>> hopefully you'll be able to compile Guile.
>
> Surely the point of having a version number on the object file format
> would be to actually take notice of it, and to change the number when
> we make format changes...?
>
> (I'm assuming that this problem was caused by a format change...)

Yes.

Currently, the code just checks for the magic cookie (see
`make_objcode_by_mmap ()'), and if it differs, e.g., because the version
isn't right, it just bails out.

Eventually, maybe it could handle this gracefully.  For instance, if
said object file is from the cache, then it could just recompile and
overwrite it with a new object file.

Then it could also try to interpret version numbers and determine
whether that bytecode is really incompatible, or whether it can
interpret it.

Thanks,
Ludo'.

Re: Build failure on master

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Currently, the code just checks for the magic cookie (see
> `make_objcode_by_mmap ()'), and if it differs, e.g., because the version
> isn't right, it just bails out.

Thanks for confirming that.

> Eventually, maybe it could handle this gracefully.  For instance, if
> said object file is from the cache, then it could just recompile and
> overwrite it with a new object file.

Yes, this is what I'd (intuitively, but without detailed knowledge)
expect.

> Then it could also try to interpret version numbers and determine
> whether that bytecode is really incompatible, or whether it can
> interpret it.

Are there scenarios where that would be worthwhile?

Regards,
    Neil

Re: Build failure on master

[Ludovic Courtès]

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> Eventually, maybe it could handle this gracefully.  For instance, if
>> said object file is from the cache, then it could just recompile and
>> overwrite it with a new object file.
>
> Yes, this is what I'd (intuitively, but without detailed knowledge)
> expect.

I guess this could be achieved by setting up a dynwind/catch block in
`primitive-load-path' when loading things from the cache.  Something to
look at once 1.9.1 is released.

>> Then it could also try to interpret version numbers and determine
>> whether that bytecode is really incompatible, or whether it can
>> interpret it.
>
> Are there scenarios where that would be worthwhile?

Maybe, e.g., when the `.go' version is known to be a strict subset of
the current objcode version.

Thanks,
Ludo'.

Re: Build failure on master

[Andy Wingo]

On Sun 12 Jul 2009 17:21, Mike Gran <spk121@yahoo.com> writes:

> I'm finding that master fails to build with the following terminating
> error:
>
> ---
>
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
> "ice-9/lineio.go" "ice-9/lineio.scm"
> ERROR: In procedure make_objcode_by_mmap:
> ERROR: bad header on object file: "GOOF-0.5"
> make[2]: *** [ice-9/lineio.go] Error 1
> make[2]: Leaving directory `/home/mike/Documents/guile/module'

Just a note to say you'll find this again now, I've bumped the objcode
version again. Make clean in module/, and remove your ~/.cache/guile
dir. We should figure out a solution that's easier...

Andy
-- 
http://wingolog.org/

Re: Build failure on master

[Andy Wingo]

On Wed 15 Jul 2009 00:05, ludo@gnu.org (Ludovic Courtès) writes:

>>> Then it could also try to interpret version numbers and determine
>>> whether that bytecode is really incompatible, or whether it can
>>> interpret it.
>>
>> Are there scenarios where that would be worthwhile?
>
> Maybe, e.g., when the `.go' version is known to be a strict subset of
> the current objcode version.

We could do that, yes. Treat the version N.M as compatible with O.P if
N==O and P <= M in the ascii sequence.

Andy
-- 
http://wingolog.org/