[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ffcall on Darwin/PPC
Re: ffcall on Darwin/PPC
Sun, 18 Mar 2007 17:11:09 +0100
Mozilla Thunderbird 1.0.2 (X11/20070113)
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
> 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?
Re: ffcall on Darwin/PPC, Yves de Champlain, 2007/03/18