This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: New libffi release? Other misc issues.
- From: Anthony Green <green at moxielogic dot com>
- To: Thomas Petazzoni <thomas dot petazzoni at free-electrons dot com>
- Cc: libffi-discuss at sourceware dot org
- Date: Tue, 5 Feb 2013 17:41:40 -0500
- Subject: Re: New libffi release? Other misc issues.
- References: <20130205004232.579026ed@skate>
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