Re: ffcall on Darwin/PPC

[David Ayers]

Yves de Champlain schrieb:
> 
> Le 07-03-18 à 05:57, David Ayers a écrit :
> 
> 
> BTW, it seems the only way to build libffi with gcc is to build java 
> (just objc won't do).

Hmm... that's related to a patch I dropped...  I wanted to submit a
patch to have libffi build as a target library  after I submitted the
patch to have boehm-gc be build with libobjc with garbage collection
without having to build java.

But then I had decided that making libffi a target library is not really
the final solution.  The solution would be to implement message
forwarding in libobjc proper.

But I still think that you should be able to build libffi stand alone...
at least you used to be able to...

/me updates gcc tree
/me creates a build directory
/me invokes '../trunk/libffi/configure'
/me invokes 'make' (not make bootstrap!)

and libffi builds... now 'make check' indeed fails as I believe it does
require building the full gcc tree.  Also I did not install it.  But
what issues did you have building libffi without gcc?

> I can't really follow the discussion, but my need to oversimplify 
> things leads me to the following conclusions :
> 
> 1- ffcall works better than ffi today

I would not say that ffcall works better than ffi today.  I would say
that it may work better on some platforms and potentially only with
certain versions of gcc.  Yet you could inverse that statement with
other platform/gcc combinations.

IOW, YMMV and I don't think it makes sense to prefer one over the other
in a general statement currently.  Instead we should rather collect the
"information" which combinations /don't/ work.  Now whether that
"information" is collected:
- statically and potentially documented in the prerequisites or
- dynamically by our configure scripts that simply report failures,
is something I don't feel strongly about.

It's just important to me that we don't suggest that one is generally
"better" at this stage because that's simply not true.

> 2- ffi has a brighter tomorrow

Agreed.

> 3- libobjc would be better by its own (after tomorrow)

I'd try to be more precise by saying that message forwarding would
better be implemented in future versions of libobjc, but yes... that's a
task for tomorrow... I wouldn't say 'after' tomorrow since ffi support
is in gcc today, but yes it's something that someone would still have to
do.  And potentially a SoC project for gcc?

Cheers,
David