This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
New libffi release? Other misc issues.
- From: Thomas Petazzoni <thomas dot petazzoni at free-electrons dot com>
- To: libffi-discuss at sourceware dot org
- Date: Tue, 5 Feb 2013 00:42:32 +0100
- Subject: New libffi release? Other misc issues.
Hello,
I am Thomas Petazzoni, a core developer of the Buildroot project
(http://buildroot.org), an embedded Linux build system that targets a
number of architectures using cross-compilation. We obviously have a
package for libffi, which is needed at least by Python and glib. It
generally works fine for us, but I have a number of questions / misc
issues that I'd like to share:
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.
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.
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?
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?
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