Re: New libffi release? Other misc issues.

[Anthony Green <green at moxielogic dot com>]

Hi Thomas,

On Mon, Feb 4, 2013 at 6:42 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>  1) The last release of libffi has been done on April 2012. Since then,
>  the support for a number of architectures has been added. We are
>  particularly interested in the AArch64, Blackfin, Microblaze and
>  Xtensa support. We used to backport some of those patches, and we are
>  now going to use a Git version, but it would be really good if a new
>  stable release of libffi could be made. Seeing all the new features
>  that have been added since April 2012, making a new release would
>  really make sense, me thinks.

Yes, I plan on making a release soon.  I wanted to make one important
change first... see below for details.

>  2) The Git repository of libffi contains a generated configure script.
>  This is generally not considered a really good practice in terms of
>  autotools usage. Normally, the files generated by autoconf/automake
>  shouldn't be kept under version control. And in addition to that, the
>  configure script that comes in the current Git version has a flaw: it
>  doesn't generate the libffi.pc file from the libffi.pc.in template.

I'll fix the libffi.pc file issue.  I just noticed this myself.

As for committing the generated files.. I'm going to keep doing that
for now.  I come by this honestly enough, as I believe that committing
generated files was a best-practice for many years (see gcc, gdb,
etc).  I'm not sure why it is frowned upon now.  It can be a pain to
track down the right versions of the autotools to generate supported
output.

>  3) There is an issue with the latest Git version as compared to the
>  stable libffi 3.0.11 version: the libffi.pc gets generated in the
>  source tree at configure time (once the configure script is
>  regenerated), but "make install" doesn't install it. Would it be
>  possible to fix this?

Yes.

>  4) Is there a reason for libffi to install its headers
>  in /usr/lib/libffi-<version>/include/ ? This is really a non-standard
>  location compared to just /usr/include or /usr/include/libffi.
>  Wouldn't it make sense to use a more standard behavior here?

This is the "one change" I was referring to up above.

I won't go into all of the reasons this was done, but I do want to
change it.  I was hoping to change it for the next release, but I've
decided not to bother yet.  I'll need some help on the PowerPC ports
(sorting through compiler-defined macros, testing), and I can tell
right now that it will take some doing to get right.

I'm going to make a release candidate tarball tomorrow for testing.

Thanks,

Anthony Green



>
> Thanks for all the work on libffi!
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com