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