Loading external drivers

[Per Hedeland]

Klacke wrote:
>This failed build was due to the -ieee switch passed to ld
>as previously noted here in the list.

Well, as also previously noted:-), it was *really* due to a bug in some
Linux libraries - Samuel Tardieu posted a pointer to his bug report, and
added:

 Note that now that all popular Linux systems are using glibc 2.1+, the
 Erlang maintainers could remove the check for -lieee from
 configure.in, it would be much cleaner, even if the problem comes from
 the Debian libc6-dev package.

The problem with this is that, in my experience, Linux installations
tend to have any number of possible or impossible combinations of
kernels/libraries/includes and still be "popular" (that was a diplomatic
way of putting it, wasn't it?:-). I.e., just which installations will
*break* if the -lieee is removed? Are they really fewer than those where
it will fix things (and does this make it acceptable to do it)? Is there
an easy way to find out which of these is the case at configure time?
(I don't know the history of the -lieee test, but presumably it was put
in for a reason.)

>As far as I know there's no person in the OTP group who
>cares much for neither gs nor etk. 

Caring or not, for better or worse, as far as I know the "officially
supported" (whatever that might mean in the open-source context:-) GUI
is still gs - which means that etk gets attention "as time permits", and
I guess time hasn't permitted much of that lately.

Still, I believe all problems reported for the Unix version of etk have
also had fixes/workarounds posted here by our helpful open-source users
- what remains is to collect them into a comprehensive and general
patch, and unfortunately that isn't as easy as just concatentating them
(see above for one example). And then there's the Windows version of
course...

--Per Hedeland
per@REDACTED