New libffi release? Other misc issues.

New libffi release? Other misc issues.

[Thomas Petazzoni]

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

Re: New libffi release? Other misc issues.

[Luis Lavena]

On Mon, Feb 4, 2013 at 8:42 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>

Hello,

I'm answering as another libffi user...

[snipping questions about generated code in the respository]

>  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?
>

Back in 2010, I asked (subject: Headers installation into libdir?)

I was wondering why libffi 3.0.9 and current master (in GitHub) both
install ffi.h and ffitarget.h into libdir/libffi-X.Y.Z/include
directory?

===

And got this as response:

I think it's because of arch specific headers it installs.

example snippet from ffi.h:

/* Specify which architecture libffi is configured for. */
#define X86_64

So the way it's installed now is in fact correct.

You should use pkg-config in your projects, like:

gcc `pkg-config --cflags libffi` -lffi main.c

$ pkg-config --cflags libffi
-I/usr/lib64/libffi-3.0.9/include
$ pkg-config --libs libffi
-lffi

===

I ended using a patch to deal with native compilation on Windows as
pkg-config is not provided:

https://github.com/luislavena/knapsack-recipes/blob/master/libffi/3.0.11/0001-Includes-should-go-in-includedir-not-libdir.patch

Cheers,
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

Re: New libffi release? Other misc issues.

[Anthony Green]

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

Re: New libffi release? Other misc issues.

[Thomas Petazzoni]

Dear Anthony Green,

On Tue, 5 Feb 2013 17:41:40 -0500, Anthony Green wrote:

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

Ah, nice!

> >  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.

Ok.

> 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.

What usually happens is that the configure/Makefile.in generated by
autoconf/automake are not in version control, but they are generated
and kept in release tarballs. So "normal" users have generated files so
they don't have to bother with autoconf/automake version issues. Only
"developers" who want to make changes to libffi have to use the right
versions, and it's not usually the biggest problem. These days, the
autoconf/automake language is fairly stable (not completely, of
course). In Buildroot (an embedded Linux build system), we have only a
single version of autoconf/automake/libtool that we use to autoreconf a
fairly significant number of packages coming from various upstreams,
and it generally works OK (with a few exceptions, of course).

I think not having configure/Makefile.in under version control is the
most common practice. See
http://www.openismus.com/documents/linux/automake/automake.shtml:

    Most projects kept in version control have an autogen.sh script
    that runs everything up to the configure step. This is done to
    provide a standard means for generating the build files from
    scratch, as generated files should never be put under version
    control. Release tarballs ship with pre-generated configure and
    Makefile.in files, so that the installer does not need to have
    autoconf or automake installed.

> >  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.

Excellent, thanks!

> >  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.

Ok.

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

Ok, great. I'll try to give it a test then.

Thanks again,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: New libffi release? Other misc issues.

[Matthias Klose]

Am 06.02.2013 10:24, schrieb Thomas Petazzoni:
>> 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.
> 
> What usually happens is that the configure/Makefile.in generated by
> autoconf/automake are not in version control, but they are generated
> and kept in release tarballs. So "normal" users have generated files so
> they don't have to bother with autoconf/automake version issues. Only
> "developers" who want to make changes to libffi have to use the right
> versions, and it's not usually the biggest problem. These days, the
> autoconf/automake language is fairly stable (not completely, of
> course). In Buildroot (an embedded Linux build system), we have only a
> single version of autoconf/automake/libtool that we use to autoreconf a
> fairly significant number of packages coming from various upstreams,
> and it generally works OK (with a few exceptions, of course).

well, GCC is most likely an exception, and libffi is shipped with GCC too. If
having the generated files within libffi helps reducing the delta, then why not
do it?.

  Matthias