bug-libsigsegv
[Top][All Lists]
Advanced

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

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


From: Bruno Haible
Subject: Re: [bug-libsigsegv] new clisp/libffcall/libsigsegv for testing
Date: Tue, 18 Apr 2017 10:10:29 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-72-generic; KDE/5.18.0; x86_64; ; )

Hi Mojca,

> > None of clisp/libffcall/libsigsegv supports effortless cross-compilation
> > because:
> >   * libffcall and libsigsegv run behavioral tests at configure time
> >     (cf. AC_RUN_IFELSE),
> 
> I checked libffcall and I only found one such test.

There are 16 more such tests:

$ grep -rn AC_TRY_RUN configure.ac m4
m4/mprotect.m4:40:AC_TRY_RUN([$mprotect_prog
m4/mprotect.m4:50:AC_TRY_RUN(GL_NOCRASH[$mprotect_prog
m4/mprotect.m4:59:AC_TRY_RUN(GL_NOCRASH[$mprotect_prog
m4/mprotect.m4:68:AC_TRY_RUN(GL_NOCRASH[$mprotect_prog
m4/mprotect.m4:77:AC_TRY_RUN(GL_NOCRASH[$mprotect_prog
m4/shm.m4:26:AC_TRY_RUN([#include <sys/types.h>
m4/mmap.m4:36:AC_TRY_RUN(GL_NOCRASH[$mmap_prog_1
m4/mmap.m4:45:AC_TRY_RUN(GL_NOCRASH[$mmap_prog_1
m4/mmap.m4:54:AC_TRY_RUN(GL_NOCRASH[$mmap_prog_1
m4/ireg.m4:15:AC_CACHE_CHECK([IREG_DOC], [ffcall_cv_c_float_return_ireg], 
[AC_TRY_RUN(GL_NOCRASH[
m4/codeexec.m4:26:AC_TRY_RUN(GL_NOCRASH[
m4/codeexec.m4:64:     [AC_TRY_RUN([
m4/codeexec.m4:101:    [AC_TRY_RUN([
m4/codeexec.m4:157:     AC_TRY_RUN([
m4/pccstruct.m4:18:AC_TRY_RUN(GL_NOCRASH[
m4/smallstruct.m4:15:AC_CACHE_CHECK([SSR_DOC],[ffcall_cv_c_struct_return_small],[AC_TRY_RUN(GL_NOCRASH[

> 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. 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.

> 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.

> I understand that this won't be possible with zero effort, but I
> wonder whether the effort is reasonable and whether you would be
> willing to help and include patches in the sources

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.

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 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).

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

Bruno

[1] https://gmplib.org/~tege/qemu.html




reply via email to

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