libffcall
[Top][All Lists]
Advanced

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

Re: [Libffcall] new clisp/libffcall/libsigsegv for testing


From: Mojca Miklavec
Subject: Re: [Libffcall] new clisp/libffcall/libsigsegv for testing
Date: Tue, 18 Apr 2017 06:02:42 +0200

Dear Bruno,

On 18 April 2017 at 05:13, Mojca Miklavec wrote:
> On 18 April 2017 at 00:51, Bruno Haible wrote:
>>
>> You wrote in <http://tug.org/pipermail/tlbuild/2017q2/003774.html>
>> (and I couldn't reply earlier because I'm not subscribed to that list
>> and you didn't CC me):
>>
>>> I optimistically tried to cross-compile on Mac OS X, but libffcall
>>> fails to detect the proper architecture and libsigsegv's "make check"
>>> fails. I'll try to see if I can trick the compiler to avoid having to
>>> go to a different machine with different architecture just for the
>>> sake of compiling clisp (the rest of TL works just fine this way).
>>
>> 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. The libsigsegv
> library contains more, but in the context of cross-compilation on
> Darwin that should not really be an issue since cross-compiled
> binaries can be executed.

I just looked at libffcall-1.13-20170225.

I checked
    avcall/config.log
which contains:

configure:3531: checking build system type
configure:3545: result: x86_64-apple-darwin10.8.0
configure:3565: checking host system type
configure:3578: result: x86_64-apple-darwin10.8.0
configure:3623: checking host CPU and C ABI
configure:3862: result: x86_64

I then tried to build with:
    --enable-static --disable-shared \
    --build=x86_64-apple-darwin10 --host=powerpc-apple-darwin9

but then it tries some useless things like

checking for powerpc-apple-darwin9-dumpbin... no
checking for powerpc-apple-darwin9-link... no

and keeps HOST.CPU at x86_64.

I then tried with
    --host=powerpc-apple-darwin10
and despite the same kind of nonsense checks it correctly recognises the CPU:

configure:4120: checking build system type
configure:4134: result: x86_64-apple-darwin10
configure:4154: checking host system type
configure:4167: result: powerpc-apple-darwin10
configure:4190: checking host platform
configure:4215: result: powerpc-apple-darwin10


But I guess that "guessing yes/no" results from compier refusing to
run some tests then? All those tests could easily run:

checking for working shared memory... guessing no
checking whether code in malloc()ed memory is executable... guessing yes


Make then fails with

libtool: compile:  /usr/bin/gcc -x none -c avcall-powerpc.s -o avcall-powerpc.o
avcall-powerpc.s:5:no such instruction: `mflr r0'
avcall-powerpc.s:6:no such instruction: `stmw r29,-12(r1)'
avcall-powerpc.s:7:no such instruction: `stw r0,8(r1)'
avcall-powerpc.s:8:no such instruction: `mr r29,r3'
avcall-powerpc.s:9:no such instruction: `stwu r1,-1104(r1)'
...

but that's because CFLAGS are missing. If I manually run that same
command with "-arch ppc" added, then that single build instruction
succeeds.

The following line in vacall/Makefile.in (it's not the only one) is
missing CFLAGS:

vacall-powerpc.o : vacall-powerpc.s
    $(CC) @GCC_X_NONE@ -c vacall-powerpc.s

Same thing is true for lots of lines in trampoline/Makefile.in:

    $(CC) @GCC_X_NONE@ -c $(srcdir)/cache-powerpc-$${syntax}.s ; mv
cache-powerpc-$${syntax}.o cache-powerpc.o

and callback/vacall_r/Makefile.in ... and perhaps most other lines in
all Makefiles as well.

Is there any chance to fix this?

Thank you,
    Mojca



reply via email to

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