home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: karish@mindcraft.com (Chuck Karish)
-
- In article <1992Feb22.073646.18830@uunet.uu.net> cmr@cvedc.prime.com
- (Chesley Reyburn) writes:
- >Submitted-by: cmr@cvedc.prime.com (Chesley Reyburn)
- >barmar@think.com (Barry Margolin) writes:
- >>What about the kind of stuff that one needs dlopen() for, i.e. where a
- >>runtime-specified module must be linked in? That's a source-level view.
-
- The charge of the POSIX.1 committee was to codify existing
- practice in the industry. I think the examples of prior art used
- to represent existing practice were 4.2BSD and System 5 Release 1.
- Neither of these supported dynamic linking.
-
- >Thank you! I sent mail yesterday to Mr. Lewine stating the same
- >thing and proposing something like:
- >
- > void *(*local_func())(char *filename, char *entryname)
- >
- >Where local_func() is part of POSIX. Filename is a fully qualified
- >file name where the source code that describes the function may be found.
- >Entryname describes the entry point in the object.
-
- The problem, of course, is that local_func() is not part
- of POSIX.1. If the POSIX.1 work were starting today,
- dynamic linking would probably be a part of the committee's
- work and would probably be the subject of a battle over
- what model to adopt.
-
- As Don Lewine pointed out, POSIX.1 does not contain any
- concept of compiling or linking. That's handled, for now,
- in an optional section of POSIX.2. The right place for
- dynamic linking in the POSIX scheme would be in POSIX.1, but
- it would require a change in that standard's scope as
- well as consideration of the constraints this would
- impose on other standards.
-
- Chuck Karish karish@mindcraft.com
- Mindcraft, Inc. (415) 323-9000
-
-
- Volume-Number: Volume 27, Number 5
-
-