From: David Daney <ddaney@avtrex.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: Gerald Pfeifer <gerald@pfeifer.com>,
java-patches@gcc.gnu.org, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] PR libffi/23935: libffi headers installed in wrong directory.
Date: Wed, 13 Sep 2006 16:31:00 -0000 [thread overview]
Message-ID: <4508325A.5050801@avtrex.com> (raw)
In-Reply-To: <84fc9c000609130129w329bd2d7mbed42e1c84dff89a@mail.gmail.com>
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.
next prev parent reply other threads:[~2006-09-13 16:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-11 23:41 David Daney
2006-09-12 4:10 ` Mark Mitchell
2006-09-12 4:14 ` Andrew Pinski
2006-09-12 16:03 ` Tom Tromey
2006-09-12 10:19 ` Anthony Green
2006-09-13 0:59 ` Gerald Pfeifer
2006-09-13 1:07 ` David Daney
2006-09-13 8:29 ` Richard Guenther
2006-09-13 16:31 ` David Daney [this message]
2006-09-15 17:23 ` Gerald Pfeifer
2006-09-13 16:41 ` Tom Tromey
2006-09-24 17:28 ` Gerald Pfeifer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4508325A.5050801@avtrex.com \
--to=ddaney@avtrex.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gerald@pfeifer.com \
--cc=java-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).