This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.0 Release Criteria
- To: dje at watson dot ibm dot com
- Subject: Re: GCC 3.0 Release Criteria
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Sun, 30 Apr 2000 16:31:08 -0700
- Cc: gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <200004302255.SAA29998@mal-ach.watson.ibm.com>
>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:
David> When you propose making libgcc a shared library on
David> many systems, do you mean GNU/Linux and other open source
David> operating systems, or are you referring to most commercial
David> operating systems as well?
I will try to clarify. Take AIX as an example system for the
statements below.
I believe that when GCC is configured with --enable-shared (meaning
that, for example, libstdc++ will be built in both shared and static
forms) then libgcc should be built in both shared and static forms.
When creating a static library, none of this is an issue.
When creating a shared library, users will link against the shared
libgcc. This does not really increase their distribution headaches --
they already have to distribute the shared library, so distributing
libgcc as well is only a minor additional nuisance.
When creating an executable that is entirely statically linked, they
can link against the static libgcc.a. This is the status quo.
When creating an exectuable linked against shared libraries, but such
that the shared libraries are known not to be linked against libgcc,
then the application can link against either the static version of
libgcc. For example, if the application links against the AIX C
library, but no other shared libraries, the application distributor
can link with the static version of libgcc. This is the status quo.
When creating an executable linked against shared libraries that are
themselves linked against libgcc (say, for example, the GNOME
windowing libraries) the application must be linked against the shared
libgcc so that their is only one version in the resulting application.
In this case, the end-user either already has GNOME (in which case
they already have a shared libgcc), or the application distributor is
shipping the shared GNOME libraries (in which case shipping a shared
libgcc as well is not a major additional inconvenience.)
So, in all cases, the additional burden is minor: the burden of
shipping a shared libgcc is never introduced where the application was
not already shipping a shared library in the first place.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com