[PATCH] PR libffi/23935: libffi headers installed in wrong directory.

[David Daney]

Richard Guenther wrote:
> On 9/13/06, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> 
>> On Mon, 11 Sep 2006, David Daney wrote:
>> > 2006-09-11  David Daney  <ddaney@avtrex.com>
>> >
>> >       PR ffi/23935
>> >       include/Makefile.am: Install both ffi.h and ffitarget.h in
>> >       $(libdir)/gcc/$(target_alias)/$(gcc_version)/include.
>> >       aclocal.m4: Regenerated for automake 1.9.6.
>> >       Makefile.in: Regenerated.
>> >       include/Makefile.in: Regenerated.
>> >       testsuite/Makefile.in: Regenerated.
>>
>> Yeah!  Could we get this on the 4.1 branch as well?
> 
> 
> I don't think we want this change on the 4.1 branch.  In fact I am
> not entirely convinced this particular fix (libffi) is correct.  libffi
> is used in separate projects as well, so separate packaging creates
> interesting dependencies if you use different compilers (though
> you can of course copy the headers around for this case).
> 

That is kind of a different question.

libffi is really only used internally to libgcj AFAIK.  It is only 
needed when building libjcj but not when compiling or linking java 
programs.  So there is really no reason to install the stand alone 
libffi and associated header files.

libgomp, libdecnumber, libssp, libmudflap, etc. are all needed to 
support different compiler features.  The stand alone libffi is not like 
these as its presence is never required as a mere result of using GCC.

There are other libraries that libgcj uses internally (boehm-gc, zlib) 
that are not installed into the compiler installation directory.  Why 
libffi is installed, I do not know.  But it does seem a little strange 
to me.

David Daney.