[Top][All Lists]

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

Re: [bug-libsigsegv] new clisp/libffcall/libsigsegv for testing

From: Mojca Miklavec
Subject: Re: [bug-libsigsegv] new clisp/libffcall/libsigsegv for testing
Date: Tue, 18 Apr 2017 17:25:02 +0200

Dear Bruno,

On 18 April 2017 at 10:10, Bruno Haible wrote:
> Hi Mojca,
>> in the context of cross-compilation on
>> Darwin that should not really be an issue since cross-compiled
>> binaries can be executed.
> If you can run the compiled binaries on the machine on which you compiled
> them, that does not count as cross-compilation for me.

I mostly agree, but different people have different views about the
topic and in fact I don't know which expression is the correct one to
describe "compiling for the platform that's not the native one, but
can run on the machine". I considered "Cross compilation" to be the
easiest approximation that's probably not technically correct.

> libffcall and libsigsegv
> should perfectly support this (since they look at the value of the --host
> option, not of the --build option). clisp may have bugs in this area, but is
> close to supporting this as well.

But I had the impression that providing "--host" triggers the mode
where some configuration tests are no longer being run. I don't use
"--host" in any other software that I compile for i386 or ppc,
providing CFLAGS/CXXFLAGS/LDFLAGS is usually perfectly sufficient.

>> If nothing else, I've seen x86_64-solaris on your list of target
>> platforms. I'm not sure about all dirty details, but from what I
>> understand one cannot install 32-bit or 64-bit system. There's only
>> one OS and one can either compile 32-bit or 64-bit binaries, depending
>> on the compiler (options). Both binaries run fine.
> Absolutely. libffcall and libsigsegv should perfectly support this.

OK, that's good news, so we should get this fixed and working.

> Regarding compiling for a non-default ABI (e.g. for mingw on cygwin, or
> for x86 or x32 on x86_64): this is supported and I gladly accept patches
> when you notice that it does not work out-of-the-box.

The first problem I noticed and reported (to libffcall list only) are
the missing CFLAGS when calling the compiler. The problem is that I
don't quite understand how the build system works. Usually there would
be Makefile.am, but your build system has some kind of
"Makefile.devel" and then "Makefile.in" files are distributed. I don't
know how exactly those faulty "Makefile.in" files are generated, so I
don't know where to patch stuff.

Regarding libsigsegv I'm still somewhat lost. The build succeeds, but
then chokes with Bus errors and I don't know where to start looking.
Any hints/suggestions?

/path/to/libsigsegv-2.11/build-aux/test-driver: line 107: 25967 Bus
error               "$@" > $log_file 2>&1
FAIL: sigsegv1

> Regarding real cross-compilation (e.g. for AIX / powerpc64 on Mac OS / 
> x86_64):
> this is not supported, and the priority for implementing it is low.

I don't need that.

>> I would like to set up fully
>> automated builds and would (consciously) like to avoid having to stack
>> up piles of hardware from nineties just for the sake of being able to
>> compile a single binary.
> In order to build clisp binaries for a certain platform, you need a build
> environment in the host environment. This may be
>   - old hardware (e.g. Mac OS X 10.3 / PowerPC),
>   - emulated hardware (e.g. Linux/mips or Linux/alpha emulated by qemu), or
>   - the "user mode" emulation of qemu (which doesn't work for me so far).

I would still like to figure out if fixing the build system to produce
functional binaries is feasible. Then I don't need to go to great
lengths installing weird emulation software. Just "gcc -arch i386/ppc"
(and perhaps some more flags to compile for 10.5 on 10.6) always
worked fine for me (unless the build system was "broken" in some way
or the desired architecture was not supported).

> Your choice. I use qemu emulations for those systems [1] for which no real
> hardware is readily accessible.

I would go for "almost native compilation", whatever the proper
technical term is (for compiling with "gcc -arch ppc").


Oh ... wait a moment.

I now retried the builds. Given that CFLAGS are not yet respected, I replaced
    CFLAGS="-arch ppc"
    CC="gcc -arch ppc"

and noticed the following

checking build system type... i386-apple-darwin10.8.0
checking host system type... i386-apple-darwin10.8.0

This reminded me that there is a bug in config.guess that returns
i386-apple-darwin10.8.0 instead of powerpc-apple-darwin10.8.0.

After patching config.guess I was able to build libffcal and all the
tests passed. Nonetheless, the compiler flags are still missing (and
needed, for example to make the binary work on a slightly older OS).

I tried the same for libsigsegv, but without success. The compilation
succeeds, but all the tests still fail with Bus error and I'm pretty
lost there. I won't even start playing with clisp until problems with
those two libraries are sorted out.

Thank you very much,

Attachment: config.guess-ppc.diff
Description: Text document

reply via email to

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