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

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

[David Daney]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

This is not a regression, but Mark has indicated in the past that these 
types of installation problems should be fixed even at this late stage.

There are two changes here really:

1)  ffi.h was moved from $(includedir) to 
$(libdir)/gcc/$(target_alias)/$(gcc_version)/include.  This fixes the 
problem noted in the PR.

2) In order to be at all useful, ffitarget.h must be in the compiler's 
search path.  It was in 
$(libdir)/gcc/$(target_alias)/$(gcc_version)/include/libffi, which does 
not meet that criterion.  I moved it to the same place as ffi.h.

Regression tested on i686-pc-linux with no regressions (but installation 
problems tend not to be exercised by the testsuite)

I also tested building a couple of the libffi testsuite tests out of 
tree to confirm that the headers are properly found by gcc (and the are).


OK to commit?

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.

[-- Attachment #2: pr23935.d --]
[-- Type: text/plain, Size: 647 bytes --]

Index: include/Makefile.am
===================================================================
--- include/Makefile.am	(revision 116759)
+++ include/Makefile.am	(working copy)
@@ -5,12 +5,8 @@
 DISTCLEANFILES=ffitarget.h
 EXTRA_DIST=ffi.h.in ffi_common.h
 
-hackdir=$(includedir)
-
-hack_DATA= ffi.h
-
 # Where generated headers like ffitarget.h get installed.
 gcc_version   := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
-toollibffidir := $(libdir)/gcc/$(target_alias)/$(gcc_version)/include/libffi
+toollibffidir := $(libdir)/gcc/$(target_alias)/$(gcc_version)/include
 
-toollibffi_HEADERS = ffitarget.h
+toollibffi_HEADERS = ffi.h ffitarget.h

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

[Mark Mitchell]

David Daney wrote:
> This is not a regression, but Mark has indicated in the past that these 
> types of installation problems should be fixed even at this late stage.

Definitely.

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

Assuming no objections from the libffi maintainers within 48 hours, this 
is fine.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[Andrew Pinski]

On Mon, 2006-09-11 at 21:10 -0700, Mark Mitchell wrote:
> Assuming no objections from the libffi maintainers within 48 hours, this 
> is fine.

Do we officially have libffi maintainers?  I know libffi is not
officially __yet__ a GNU project but it would be a good idea to assign a
maintainership to it now before it becomes an official project.


Green,
  Do you have an update on the libffi status with respect of copyright
to the FSF?


Thanks,
Andrew Pinski

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

[Anthony Green]

On Mon, 2006-09-11 at 16:41 -0700, David Daney wrote:
> 1)  ffi.h was moved from $(includedir) to 
> $(libdir)/gcc/$(target_alias)/$(gcc_version)/include.  This fixes the 
> problem noted in the PR.
> 
> 2) In order to be at all useful, ffitarget.h must be in the compiler's 
> search path.  It was in 
> $(libdir)/gcc/$(target_alias)/$(gcc_version)/include/libffi, which does 
> not meet that criterion.  I moved it to the same place as ffi.h.

These changes look good to me.  

We should eventually merge these two files into one, since the idea of
having target dependent and independent headers doesn't seem to be
helpful anymore.

Thanks,

AG

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

[Tom Tromey]

>>>>> "Andrew" == Andrew Pinski <pinskia@physics.uc.edu> writes:

Andrew> Do we officially have libffi maintainers?

Historically the java maintainers, and especially Anthony, have
approved generic changes; Andreas owns the test suite; and changes to
the ports have been approved either by java maintainers or by GCC back
end maintainers.

This isn't documented however.

Tom

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

[Gerald Pfeifer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 823 bytes --]

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?

With this fix, the only major issue that prevents installing two full 
installations of GCC into the same prefix (with suitable --libdir, 
--infodir and --program-suffix options and ignoring man pages for a
minute¹) is lib/pkgconfig/libgcj.pc.

Is there any chance we can get this final bit addressed as well?

Gerald

¹ Is there agreement that man pages should also honor --program-suffix?

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

[David Daney]

Gerald Pfeifer 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 know if I would have time to do it.  Also approval from the RM 
would probably be needed.  But if he did approve, you could just test it 
on the branch yourself and do the commit.

David Daney

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

[Richard Guenther]

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

> With this fix, the only major issue that prevents installing two full
> installations of GCC into the same prefix (with suitable --libdir,
> --infodir and --program-suffix options and ignoring man pages for a
> minute¹) is lib/pkgconfig/libgcj.pc.

The solution for this is either not installing it or renaming the file
like libgcj42.pc - we cannot move it.

> Is there any chance we can get this final bit addressed as well?

Final?  I think ada is also broken.

Richard.

> Gerald
>
> ¹ Is there agreement that man pages should also honor --program-suffix?

They do.  info pages don't.  Likewise translation files.  And ada does
not honour it and installs unversioned (yay) shared libraries.

Re: [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.

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

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:

Gerald> With this fix, the only major issue that prevents installing two full
Gerald> installations of GCC into the same prefix (with suitable --libdir,
Gerald> --infodir and --program-suffix options and ignoring man pages for a
Gerald> minute¹) is lib/pkgconfig/libgcj.pc.

Gerald> Is there any chance we can get this final bit addressed as well?

Sure.  I just didn't know about it...

Gerald> ¹ Is there agreement that man pages should also honor --program-suffix?

FWIW Automake applies the program rename transform to the base name of
man pages.

Tom

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

[Gerald Pfeifer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 655 bytes --]

On Wed, 13 Sep 2006, Richard Guenther wrote:
> Final?  I think ada is also broken.

Oh, well.  To be honest, I haven't been able to (easily) build Ada on my 
regular test systems.

>> ¹ Is there agreement that man pages should also honor --program-suffix?
> They do.  info pages don't.  Likewise translation files.  And ada does
> not honour it and installs unversioned (yay) shared libraries.

Yucks.  As for man pages, you're mostly right -- these days it's only 
man/man7/gpl.7, man/man7/gfdl.7, and man/man7/fsf-funding.7 which conflict 
if you install under the same prefix using --program-suffix.  I'm not sure
what to do about these three.

Gerald

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

[Gerald Pfeifer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 604 bytes --]

On Wed, 13 Sep 2006, Tom Tromey wrote:
>> With this fix, the only major issue that prevents installing two full
>> installations of GCC into the same prefix (with suitable --libdir,
>> --infodir and --program-suffix options and ignoring man pages for a
>> minute¹) is lib/pkgconfig/libgcj.pc.
>> Is there any chance we can get this final bit addressed as well?
> Sure.  I just didn't know about it...

I create Bugzilla #29205 for this now.  If you could have a look before
the release of GCC 4.2.0 and, if possible, backport to the GCC 4.1 branch
as well, that would be very, very cool!

Thanks,
Gerald