Subject: Re: ld: symbol __PROCEDURE_LINKAGE_TABLE_ remains undefined
To: Olaf Seibert <rhialto@polder.ubc.kun.nl>
From: None <seebs@plethora.net>
List: current-users
Date: 08/28/1998 09:44:15
In message <199808281041.MAA12977@polder.ubc.kun.nl>, Olaf Seibert writes:
>Call me stupid, but so far nobody has been able to explain to *why* ELF
>is such a Good Thing. All I know about it is that it doesn't even have
>an operating system identification in executables (needed for proper
>emulation modes or at least recognition for which OS a binary is) so
>that various OSes have kludged around this in incompatible ways. The
>fact that the Linux clan hasn't managed to do proper shared libs with
>a.out does of course not count; from NetBSD we can see that it is
>perfectly possible. Or would ELF (as in a fairy tale ;-) magically make
>shared libs much more efficient even on NetBSD platforms where they
>already exist?

That's my understanding.  Well, here's what BSDI said

	Why did BSDI switch to ELF?

	ELF dynamic linking allows applications to avoid the limitations
	caused by fixed addresses and offsets in static linking.  ELF
	executable file support brings BSD/OS in line with industry standards.
	The system now executes ELF programs in addition to a.out and COFF
	programs.

	ELF Dynamic (and Static) Libraries -- 4.0 provides dynamically linked
	versions of all of our standard libraries.  Dynamically linked ELF
	shared libraries and shared objects are a widely used industry
	standard, and they are much more flexible and maintainable than the
	statically linked shared libraries.

(Typos mine, although I fixed two of theirs.)

-s