Re: gnustep-guile and dynamic-link

[Nicola Pero]

> First of all, I've been looking more closely into GNUstep and Guile
> recently, so I am naturally interested in gnustep-guile.  I've tried
> building/installing gnustep-guile, but upon trying to run Test/test.scm,
> Greg fails to load the required libraries.  After tracking the problem
> for a little bit, and with help from the guile-user mailing list, I've
> found that the problem lies in (dynamic-link) trying to load a shared
> library with undefined external symbols.

Hm - from what you say, I suspect that you tried to run Test/test.scm
directly - while you should go into Test/test.scm and run `make check'
there if you want to run the tests.

I know it's a bit annoying, so let me explain a bit how it works.

The gnustep-guile libraries are *not* linked against gnustep-base and
libobjc.  The reason is easy - when gnustep-guile was written, libobjc was
a static library, so you couldn't really use it that way (now that libobjc
has been turned into a shared one, I think there is no longer a reason and
gnustep-guile should be fixed - I'll do it when I've got time).

So - gnustep-guile used a workaround.  To run gnustep-guile code, you
don't just run guile and then load the gnustep-guile libraries from guile
- that won't work (originally because in no way you could dynamically load
libobjc, which was static and not shared).  Instead, you create a little
executable tool, which is linked against libobjc and gnustep-base.  Then,
you start guile from the tool, and in the guile environment you get, you
can load gnustep-guile libraries from there (gnustep-base and libobjc
already being available because linked into the tool when compiled).

I personally think all this needs fixing, and people wanting to use
gnustep-guile should be required to have a shared libobjc and we could
just link gnustep-guile against libobjc and libgnustep-base and everything
and just load gnustep-guile from guile whenever we want.  We could then
drop - I think - the command line tools which are currently needed to run
gnustep-guile code.  I might work on fixing this at some point.

Anyway, all this to explain that - currently - you can't simply load
libgstep_guile from a generic guile environment.  You need to be running
the whole thing from something like the `go' command-line tool which is
provided in Test/, or the `guile-base' command-line tool which is provided
in Tools/.  If you type `make check' in Test/, and see what happens, you
should see that it's running the `go' tool, which is firing up a guile
system and executing `test.scm' inside the guile system.

> 1)  Is anyone else having a similar problem when trying to use
> gnustep-guile?

Not with guile-1.4.

I've had fun with gnustep-guile both on redhat and on debian.


> 2)  Is there any reason why the gnustep libraries are not linked to the
> libraries they require?

Yes - a historical reason - see above.