into libc. This reduces the size of every dynamically linked
executable by 248 bytes, and it reduces the size of static executables
by a lesser amount. It also eliminates some global namespace
pollution.
With this change in place, the source for dlfcn.h should probably
be moved to "/usr/src/include". I'll save that for another day.
Compatibility note: Programs which use dlopen, if compiled on
systems with this change, will not run on systems with a libc from
prior to this change. Very few programs use dlopen, so I think
that is OK.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
was apparently overlooked at the time the member was added. Its absence
causes some error messages from the dynamic linker to begin with
"(null):" instead of with the pathname of the dynamic linker as they
should.
I am also adding a work-around to the dynamic linker, to cope with
legacy binaries that were built with older versions of crt0.
just return errors. This removes the need for awful hacks like that in
our build of libtcl which would get link errors when linked static.
John Polstra once mentioned that this was on his "todo" list.
Note that one can use:
cc -Wl,-Bstatic -o foo foo.o
and get an executable that has it's libraries statically linked, but has
a fully functional runtime linker so the executable can call dlopen() and
have it work. (I've tested this)
and forwards compatable with version 3. This is needed to enable storing
a run-time library path in the dynamic linking headers. The crt startup
tries version 4 first, and falls back to version 3, so an executable that
is linked on -current will work with the ld.so on 2.1.x and less.
Reviewed by: nate, jdp
Obtained from: NetBSD
symbols.
An easy example to see this is to develop an X program which links
against Xt, but doesn't add -lX11 to the link line. It will link fine,
but cause run-time errors by ld.so because of missing symbols used by Xt
defined in X11. This patch makes the errors more readable.
Submitted by: jdp@polstra.com (John Polstra)
on dlclose. Also correctly call constructors and destructors for libraries
linked with /usr/lib/c++rt0.o.
Change interpretation of dlopen manpage to call _init() rather than init()
for dlopened objects.
Change c++rt0.o to avoid using atexit to call destructors, allowing dlclose to
call destructors when an object is unloaded.
Change interface between crt0 and ld.so to allow crt0 to call a function on
exit to call destructors for shared libraries explicitly.
These changes are backwards compatible. Old binaries will work with the new
ld.so and new binaries will work with the old ld.so. A version number has
been introduced in the crt0-ld.so interface to allow for future changes.
Reviewed by: GAWollman, Craig Struble <cstruble@singularity.bevc.blacksburg.va.us>
(void) setlocale(LC_ALL, "");
It will be easiest way now to make national chars available
for all ctype-oriented programs at once by simple:
setenv LANG Your_National_Charset
Default case (without "LANG" environment
variable) will be fully ANSI compatible (got "C" locale).
If "LANG" variable present, extention becomes active.
Effect of this extention is great: in one time all ctype
oriented programs can accept/print national characters
without any touching source/binary code, it is big win, IMHO.
This method is fully compatible with ISO8859-* and russian koi8-r
too (in general -- with all 8-bit character sets). I think
it is very useful.
I got this idea from Xenix locale implementation.
This extention is even never compiled in, unless you set
setenv STARTUP_LOCALE
before rebuilding crt0.c or corresponding variable in /etc/make.conf
program. The idea was that these are 'alignment' crap, but the image
is 16byte-aligned without these. Location 0 still doesn't have a 0,
but who cares, binaries wil be built with page zero unmapped in the
near future.
