O/T: Building ffcall on OSX 64 bit? (Fails)

[Kenny McCormack]

Totally O/T, but, yet, not really. It has to do with a GAWK extension lib.

One of the last tasks I have in finishing the call_any project is to get it
to compile and run on OSX-64. call_any is built on "avcall", which is part
of the "ffcall" package. ffcall/avcall builds OK on 32 bit OSX, but fails
on 64 bit. I have Googled this and there are several hits discussing the
problem, but no solutions. Basically, the "make" errors out with some
assembler errors.

I'm hoping there is someone out there with access to an OSX-64 system and
who has better Google Foo than I do. "ffcall" is kind of abandonware at
this point; I don't know if anyone is still maintaining it. The last time
I tried to reach someone with a question, I got no return...

I've tried a few different "configure" options, but they all fail, although
with slightly different error messages. Here's the result of my current
attempt to build:

$ make
cd avcall; make all
/bin/sh ./libtool --mode=compile gcc -x none -c ./avcall-x86_64.s
gcc -x none -c ./avcall-x86_64.s -o avcall-x86_64.o
./avcall-x86_64.s:5:2: error: unknown directive
.type __builtin_avcall,@function
^
./avcall-x86_64.s:331:2: error: unknown directive
.size __builtin_avcall,.Lfe1-__builtin_avcall
^
./avcall-x86_64.s:332:11: error: mach-o section specifier uses an
unknown section type
.section .eh_frame,"aw",@progbits
^
make[1]: *** [avcall-x86_64.lo] Error 1
make: *** [all] Error 2
$

Note that 'gcc' is really 'clang', which is subtly different than real 'gcc'.
I suspect (but cannot prove, of course) that the problem is that the
assembler built into 'clang' isn't quite the same as the one built into
'gcc', and it is enough different to cause the assembly to fail.

It is on my TODO list to build real 'gcc' on the Mac, and this may be the
incentive I need to go down that road. In the meantime, if someone has
real 'gcc' and would like to try this, I'd be interested to hear the results.

--
The motto of the GOP "base": You can't *be* a billionaire, but at least you
can vote like one.

[Kaz Kylheku]

On 2015-04-03, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> I'm hoping there is someone out there with access to an OSX-64 system and
> who has better Google Foo than I do. "ffcall" is kind of abandonware at
> this point; I don't know if anyone is still maintaining it. The last time
> I tried to reach someone with a question, I got no return...

ffcall has always been relatively obscure. I believe that it basically exists
to support CLISP. CLISP itself isn't abandonware, but development hasn't been
all that active in recent years.

> $ make
> cd avcall; make all
> /bin/sh ./libtool --mode=compile gcc -x none -c ./avcall-x86_64.s
> gcc -x none -c ./avcall-x86_64.s -o avcall-x86_64.o

These should be converted to .S files (capital S). Then preprocessing
would work (hopefully clang has the same convention) giving us #ifdef
and friends.

Finding out what the CLISP people are doing for a MacOS port might be useful.

From a glance through the mailing list, there have been issues with ffcall,
as can be expected.

[Kenny McCormack]

In article <201504030...@kylheku.com>,

Kaz Kylheku <k...@kylheku.com> wrote:
>On 2015-04-03, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> I'm hoping there is someone out there with access to an OSX-64 system and
>> who has better Google Foo than I do. "ffcall" is kind of abandonware at
>> this point; I don't know if anyone is still maintaining it. The last time
>> I tried to reach someone with a question, I got no return...
>
>ffcall has always been relatively obscure. I believe that it basically exists
>to support CLISP. CLISP itself isn't abandonware, but development hasn't been
>all that active in recent years.

Points taken.

I've found it quite useful, for many things, including GAWK's call_any.

Out of curiosity, do you know of any alternatives?

>> $ make
>> cd avcall; make all
>> /bin/sh ./libtool --mode=compile gcc -x none -c ./avcall-x86_64.s
>> gcc -x none -c ./avcall-x86_64.s -o avcall-x86_64.o
>
>These should be converted to .S files (capital S). Then preprocessing
>would work (hopefully clang has the same convention) giving us #ifdef
>and friends.

No joy. I'm assuming you're suggesting that I rename the .s to .S and see
if it helps any. Do be aware that the Mac's filesystem is
case-insensitive, which makes it unlikely that this would help (note that I
didn't say impossible, just unlikely)

>Finding out what the CLISP people are doing for a MacOS port might be useful.

If I could get hold of them...

>From a glance through the mailing list, there have been issues with ffcall,
>as can be expected.

Any details you can provide would be helpful...

--
Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
an 8 bit operating system based on a 4 bit architecture from a 2 bit company
that can't stand 1 bit of competition.

Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
operating system based on a 4 bit architecture from a 2 bit company that
can't stand 1 bit of competition.

[Kaz Kylheku]

On 2015-04-03, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> It is on my TODO list to build real 'gcc' on the Mac, and this may be the
> incentive I need to go down that road.

https://solarianprogrammer.com/2015/05/01/compiling-gcc-5-mac-os-x/

[Kenny McCormack]

In article <201505012...@kylheku.com>,

Thanks for the link. Very interesting.

--
A Catholic woman tells her husband to buy Viagra.

A Jewish woman tells her husband to buy Pfizer.