Re: guile-gtk without dlopen (HP-UX) (fwd)

[Marius Vollmer <mvo at zagadka dot ping dot de>]

Stephen Tell <tell@cs.unc.edu> writes:

> Looking in %load-path seems pretty bogus, because by default it seems to
> contain only directories under $PREFIX/share.

Yes, indeed.  It was a bad decision back then and I didn't expect it
to stick that long.  I'm now more in favor of amore explicit approach
to dynamic linking of C modules so that Guile does not need to do so
much guessing and consequently has fewer opportunities to guess wrong.

But, on the other hand, I'm pretty little motivated to do anything
about the current situation.  It seems to work in practice, to some
extent (i.e. there aren't too many complaints), and I like to wait for
the new module system.

If a package can't use Guile's built in mechanism, it can roll its
own, like guile-gtk does.

Now, guile-gtk needs to smarten up about other platforms besides
GNU/Linux.  It should do that by using Guile's dynamic-link function,
etc.

Anyway, that's the plan.

> I can get "guile-gtk -s hello-world.scm" to work with my hacked
> dynlink.scm, but not "guile -s"

Hmm, didn't "guile-gtk -s" work for you, aynway?  The executable
guile-gtk should not do any dynamic linking at all, because all
libraries are already there.

> $ guile -s ./hello-world.scm
> in sgt's hacked dynlink.scm
> module-prefix is gtk-1.2
> new merge-compiled-code guilegtk-1.2 sgtk_init_gtk_gtk_glue
> ERROR: In procedure dynamic-call in expression (dynamic-call initname dynobj):
> ERROR: undefined function

This error message comes from the HPUX implementation of
"dynamic-func".  It think it means that you loaded the library just
fine, but the init function couldn't be found.  You might want to
point GDB at "sysdep_dynl_func" and see why it's failing.

> Part of my difficulty modifying dynlink.scm is that I don't really
> understand what the rest of merge-compiled-code is trying to do -
> possibly fiddling with the module system to avoid loading anything
> twice?

The modinfo stuff?  Yes, that's supposed to deal with C modules that
have already been linked in, like with the guile-gtk executable.

> And while I'm getting tracebacks on errors within my program, I can't
> for the life of me get tracebacks from hello-world.scm, despite sprinkling
> around the usual incantation: 
> 	(debug-enable 'backtrace) (read-enable 'positions)

Yes, that's tricky sometimes.  Something needs to be done about error
reporting and debugging of Guile programs...

> But we might as well skip libguiledlopenhelper if HAVE_DLOPEN is false,
> since it isn't going to work anyway.

Yes.
 
> P.S.  The name of the environment variable containing the shared library
> path varies, by the way: "libtool --config | grep shlibpath_var" will
> yield LD_LIBRARY_PATH on linux and solaris, SHLIB_PATH on HP-UX.

Aha!  But I really expect to be using libltdl for all this platform
specific magic in the future.  I have a patch for it somewhere...

- Marius