epsilon-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build fails on MacOS/MachO: not ELF or COFF


From: Luca Saiu
Subject: Re: build fails on MacOS/MachO: not ELF or COFF
Date: Mon, 11 May 2020 19:50:01 +0200
User-agent: Gnus (Gnus v5.13), GNU Emacs 27.0.50, x86_64-pc-linux-gnu

Hello Niobos.

On 2020-05-11 at 17:13 +0000, Niobos wrote:

> Since my build-environment is a bit complicated (homebrew injecting
> current versions of flex/bison/...), I've first tried to reproduce the
> original issue using master (ec3ea52f0dceca9d8c525424ef70093095bf95a7)
> and the instructions above, with success (i.e. the build fails).

I suspect that the build directory may have been dirtied by this first
attempt.

> For the niobos branch (d43116ba9a39d093fd7b3c60ebda33939372a11c), it
> works a bit better:
>
> the build (`make`) succeeds, but the testsuite (`make check`) fails.
> What is strange is that the testsuite fails in several different ways:
>
> The first `make check` fails to compile.

In file included from example-vms/jitterlisp/jitterlisp-ast.c:23:
In file included from ./example-vms/jitterlisp/jitterlisp-ast.h:28:
In file included from ./example-vms/jitterlisp/jitterlisp.h:53:
./example-vms/jitterlisp/jitterlisp-eval-vm.h:27:10: fatal error: 
'jitterlispvm-vm.h' file not found

So the jitter executable generating a C file did not do its job.  I
suspect that the problem may be a dirty build directory.  The makefile
should handle dependency correctly, even with parallel builds.  You did
generate jitterlispvm-vm.h :

  bin/jitter \
            "./example-vms/jitterlisp/jitterlisp.jitter" \
            --output "./example-vms/jitterlisp/" \
            --template-directory="./templates/"

I cannot really explain this but I suspect something is grossly wrong
with code generation; mixing generated files from different builds,
perhaps.

> The second time, it takes a looong time (over 7 minutes on my 8-core
> 2.3GHz i9 machine), and gets to the actual tests, with 0 PASSes.
> A third run is faster, and gives the same test results (all failures/skips)
> Output of all three runs attached.

It is normal that you see a log of SKIPs.  In a non-sub-package build
you should see 50% SKIPs on a 64-bit architecture: the skipped test
cases are the same test cases for advanced dispatches, minimal-threading
and no-threading.  The other half, that you are actually running, is for
switch and direct-threading.

A few tests require 64-bit integers and are therefore skipped on 32-bit
architectures, but that is not your case.

The test suite is heavyweight and it is normal that it takes a lot of
time, but zero passes is absolutely not normal.  Does every test case
time out ?  Do you see them all failing after a fixed number of seconds,
maybe 3?

I might be doing something non-portable in the test suite machinery.

Can you please send me a tarball of your tests/ build subdirectory?

On my machine
  tar c tests/ | xz -9 | wc -c
shows about 3MB.  Since half of your testcases is disabled your tarball
size should be more or less halved as well.

I am not sure if the mailing list will accept such a relatively large
attachment; in doubt, just send the file privately to me using the email
box I am using now.  We will then continue the discussion in public.

> I'd gladly run more tests for you, but do let me know if I can
> contribute in a more meaningful way.

You are being very helpful.  I am sure that this portability work will
make the code more robust.

If this issue turns out to be difficult to debug we could maybe arrange
some way to let me access your machine over ssh; but right now I think I
can learn about the next problem from the tests/ tarball.

Thank you,

-- 
Luca Saiu
* My personal web site:  http://ageinghacker.net
* GNU epsilon:           http://www.gnu.org/software/epsilon
* Jitter:                http://ageinghacker.net/projects/jitter

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]