This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]