Loading external drivers

[Klacke]

> > >
> > > After relinking with `-rdynamic' flag this problem was solved.
> >
> > That is indeed correct.
> 
> Could this also be screwing up ETk? I'm not sure how to tell if it is
> installed as a external driver in the standard install. Does Etk work under
> Unix/X in R6B?
> 

Not really, etk runs (or ehum, rather used to run) in either
of two modes. The default is try to run etk in an external
unix process, the option {driver, "etk_drv"} should start etk
as a linked in driver (which I believe is the default on win32, 
can't verify that since I'm in blissful ignorance of the win32
stuff)

However, etk did not work in r6b, !!!!
First of all the .so file didn't build. At least not on linux.
(It builds nice on FreeBSD)

This isn't as bad as it sounds since the etk unix 
program is the default. Neverthe less it should build.
This failed build was due to the -ieee switch passed to ld
as previously noted here in the list.

Here's a patch for that:

otp_src_R6B-0> diff -c lib/etk/configure.in.orig lib/etk/configure.in
*** lib/etk/configure.in.orig   Sat Dec 11 01:55:21 1999
--- lib/etk/configure.in        Sat Dec 11 01:55:33 1999
***************
*** 134,140 ****
  #--------------------------------------------------------------------
  
  AC_CHECK_FUNC(sin, MATH_LIBS="", MATH_LIBS="-lm")
! AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"])
  
  #--------------------------------------------------------------------
  #     Supply substitutes for missing POSIX header files.  Special
--- 134,140 ----
  #--------------------------------------------------------------------
  
  AC_CHECK_FUNC(sin, MATH_LIBS="", MATH_LIBS="-lm")
! #AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"])
  
  #--------------------------------------------------------------------
  #     Supply substitutes for missing POSIX header files.  Special
***************
*** 1335,1341 ****
  
  MATH_LIBS=""
  AC_CHECK_FUNC(sin, , MATH_LIBS="-lm")
! AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"])
  
  #--------------------------------------------------------------------
  #     If this system doesn't have a memmove procedure, use memcpy
--- 1335,1341 ----
  
  MATH_LIBS=""
  AC_CHECK_FUNC(sin, , MATH_LIBS="-lm")
! #AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"])
  
  #--------------------------------------------------------------------
  #     If this system doesn't have a memmove procedure, use memcpy



The second error was lot worse. It appears as if the etk exec
as well as the .so file now resides in etk/priv/bin/$(TARGET)
instead of as before etk/priv/bin. Oops.

Here's a fix for that:

otp_src_R6B-0> diff -c lib/etk/c_src/Makefile.in.orig lib/etk/c_src/Makefile.in
*** lib/etk/c_src/Makefile.in.orig      Sat Dec 11 01:58:04 1999
--- lib/etk/c_src/Makefile.in   Sat Dec 11 01:58:09 1999
***************
*** 191,197 ****
  
  ETK_SRC_DIR =           $(ETK_DIR)/c_src
  ETK_ERL_DIR =           $(ETK_DIR)/src
! ETK_BIN_DIR =         $(ETK_DIR)/priv/bin/$(TARGET)
  
  OBJDIR =              $(TARGET)
  
--- 191,197 ----
  
  ETK_SRC_DIR =           $(ETK_DIR)/c_src
  ETK_ERL_DIR =           $(ETK_DIR)/src
! ETK_BIN_DIR =         $(ETK_DIR)/priv/bin
  
  OBJDIR =              $(TARGET)




However, (still on linux rh6.1) I can't get the
-withdrawn option to work
$ etk/priv/bin/etk -withdrawn 
Just hangs, tk:start() works though,


> I didn't really want to spend weeks getting ETk working so I've gone back to
> the old Erlang release while I work on my widget. 

Wise move 

> Is it my imagination or
> are the maintainers not very interested in fixing this? (or maybe they're
> just busy)
> 

No I think this is the case. 

etk was written by Tony Rogvall
who's now at bluetail hacking smtp servers. The etk code is
great, the only trouble is that it's written to work with a
by now fairly old tk version (4.2)

The source for gs sucks. gs is also written to interface old
tk 4.2.

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

Somebody ought write an essay on the gui programming
interfaces we've had over the years.  Uhhhh.

Personally I'm writing an interface to gtk+ instead :-)


Cheers


PS. As for the patches above, since they patch configure.in,
we need to rerun autoconf and configure (in the lib/etk directory)


/klacke


-- 
Claes Wikstrom                          <klacke@REDACTED>
Bluetail AB                             http://www.bluetail.com