karron@MCIRPS2.MED.NYU.EDU (09/24/90)
I am working on a archive of library functions, and as the library changes, I would like to NOT have to relink the .o files to the library in the executable make file. How do I make the library archive share-able, and have it linked at run time ? dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu Dan Karron | | . . . . . . . . . . . . . . New York University Medical Center | | 560 First Avenue \ \ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \**\__________________________________________ | +-----------------------------------------------------------------------------+
jim@baroque.Stanford.EDU (James Helman) (09/25/90)
A while back, I thought about creating a shared library, but changed
my mind after looking in the "Building a Shared Library" part of the
Programmer's Guide. It appears to be quite painful to create shared
libraries under IRIX. In particular, as I understand it:
1) Imported symbols cannot be referenced directly. You need to
get a pointer into the library's data and use indirection. Calls
are handled transparently through a branch table created in the
shared library.
2) If an external symbol moves, you must relink all a.out files
that use that shared library. (So you have to be sure to put all
your externally visible static data in a separate file and archive
it in first otherwise a new string literal or compiler generated
switch table in another object file could move them.)
3) Every application using a shared library, gets its own private
copy of the entire library's data section, i.e. no copy-on-write.
4) When a shared library imports symbols from another shared
library, calls are no longer transparent. They must be made
through a pointer, e.g. (*_libc_malloc)(n), and the corresponding
initialization, e.g. _libc_malloc = &malloc, must be part of the
staticly linked code. This would affect any user generated shared
library using libc_s.
5) Shared libraries must be preallocated regions in memory. If
you give out a package with your own shared library, there's no
guarantee that someone else hasn't already used that region!!!!
Please correct me if I'm wrong on any of this.
It looks MUCH easier under SunOS. I believe that SVR4 has improved
shared library support, but I don't know if it's compatible with Sun's
(I hope so), OSF's (?, they must have one) or SGI's current offering.
Anyone care to clue us in to what the future holds for IRIX and shared
libs. Will IRIX be tracking SVR4 or some other UN*X "standard" in
this regard?
Thanks,
Jim Helman
Department of Applied Physics Durand 012
Stanford University FAX: (415) 725-3377
(jim@KAOS.stanford.edu) Work: (415) 723-9127guy@auspex.auspex.com (Guy Harris) (09/26/90)
>shared library support, but I don't know if it's compatible with Sun's >(I hope so), It's *derived* from Sun's, so it's basically compatible (some command line options may have changed a bit). >or SGI's current offering. If SGI's is based on S5R3, S5R4's isn't compatible, 'cuz S5R4's shared libraries aren't the same as S5R3's.