This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SunOS shared libs ?
- To: law at cygnus dot com
- Subject: Re: SunOS shared libs ?
- From: Manfred Hollstein <manfred at s-direktnet dot de>
- Date: Fri, 10 Jul 1998 13:06:59 +0200 (MET DST)
- Cc: ram at netcom dot com, egcs at cygnus dot com
- References: <13732.58164.680856.974625@slsvhmt> <1144.900047547@hurl.cygnus.com>
- Reply-To: manfred at s-direktnet dot de, Manfred dot Hollstein at ks dot sel dot alcatel dot de
On Thu, 9 July 1998, 23:12:27, law@hurl.cygnus.com wrote:
>
> In message <13732.58164.680856.974625@slsvhmt>you write:
> > if (constructors.number == 0 && destructors.number == 0
> > && frame_tables.number == 0
> > #if defined (SCAN_LIBRARIES) || defined (COLLECT_EXPORT_LIST)
> > /* If we will be running these functions ourselves, we want to emit
> > stubs into the shared library so that we do not have to relink
> > dependent programs when we add static objects. */
> > && ! shared_obj
> > #endif
> > )
> >
> > Obviously, the *.number == 0 checks are all true, and shared_obj is
> > also true, hence it's going the write_c_file way. Does anybody know,
> > why the stubs are still required, even if no CTOR/DTORs or frame
> > tables are available? I think, this is plain wrong.
> I believe this is the desired behavior.
>
> Imagine if you later recreate the library -- without changing the
> interfaces, but it now has an object that needs constructing.
>
> If you don't have the stubs already in the library, then any program
> that was linked against the library will need to be re-linked against
> the new library.
Ahh, good point; agreed.
manfred