home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!hp-cv!hp-pcd!hpfcso!mjs
- From: mjs@hpfcso.FC.HP.COM (Marc Sabatella)
- Newsgroups: comp.sys.hp
- Subject: Re: CC and /usr/lib/dld.sl
- Message-ID: <7371278@hpfcso.FC.HP.COM>
- Date: 1 Sep 92 17:50:55 GMT
- Article-I.D.: hpfcso.7371278
- References: <1992Sep1.091000.14893@irfu.se>
- Organization: Hewlett-Packard, Fort Collins, CO, USA
- Lines: 30
-
- In comp.sys.hp, jhd@irfu.se (Jan D.) writes:
-
- > Anybody know why CC (HP C++ B2402 A.02.34 on a 730, HP-UX 8.07)
- > always link in /usr/lib/dld.sl even if you say -Wl,-a,archive?
- >
- > What does it do with it and is there anyway to get rid of it?
-
- What it does is use shl_get(3X) and shl_findsym(3X) to locate all static
- constructors within shared libraries so it can execute them at startup time.
- There was no easy way for "CC" to know if this was necessary or not - ie, it
- doesn't parse the "ld" options to find out if you are using shared libraries or
- not - so it always links in that library.
-
- If you don't mind this miniscule use of libdld.sl - one call to shl_get(3X) is
- enough to convince CC there are no other shared libraries to worry about, then
- just leave things alone. If for some reason you can't tolerate even the
- dependency on libdld.sl, you can use the output of "CC -v" to construct your
- own link line (don't forget to run c++patch as shown by "CC -v" as well) and
- leave off /usr/lib/libdld.sl, and provide dummy definitions of shl_get(3X) and
- shl_findsym(3X).
-
- BTW, libC also makes references to shl_load and shl_unload, but those are only
- to enable implementation of cxxshl_load and cxxshl_unload; if you aren't using
- the latter, you won't need the former.
-
- --------------
- Marc Sabatella (marc@hpmonk.fc.hp.com)
- Disclaimers:
- 2 + 2 = 3, for suitably small values of 2
- Bill (H.) and Dave (P.) may not always agree with me
-