[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Embeding GST in an application
From: |
David Forster |
Subject: |
[Help-smalltalk] Embeding GST in an application |
Date: |
Mon, 8 Oct 2001 04:41:26 -0600 |
User-agent: |
Mutt/1.3.22i |
I've been fooling around with GST a bit and have been trying to get it
to work from an application (that is, initializing the VM from my own C
application (instead of having `gst' dlopen() a module). The info
manual says this is OK, but I've been running into a few problems:
- First, libgst.a isn't installed. The Makefile.am replaces (not
augments as maybe was expected?) install-libLTLIBRARIES so that the
optimize rule is run. Perhaps it would be better to have a
--enable-debug switch for configure? I assume most people want the
optimized build anyways, it's actually slowing people down building
both as is.
- Is there a particular reason why there is no libgst.so? Is it to
save build time as before?
- One must install callin.h in order to access stringToOOP(), etc. w/o
a VMProxy struct. The include for gst.h has to be removed to get it
to work outside the tree...
- The VM is flaky for some reason when run like this. For example,
with just a plain vanilla main() (just like main.c in gst),
executing '3 printNl!' causes the following:
st> 3 printNl!
Execution begins...
stdin:1: Segmentation violation
FileStream>>#flush
FileStream>>#nextPutAllFlush:
TextCollector>>#primNextPutAll:
[] in TextCollector>>#showCr:
Semaphore>>#critical:
TextCollector>>#showCr:
SmallInteger(Object)>>#printNl
UndefinedObject>>#executeStatements
<bottom>
Segmentation fault
I've tried both optimized and `normal' builds of libgst.a. My main()
looks just like GST's...
I'd like (if possible) to link libgst.a instead of .so modules since
GDB strongly dislikes dlopen() and .so's on some platforms (BSD). GDB
is even a little flaky on GNU platforms in this area...Being able to
do static builds might make things easier.
Is there any support for fixing this? Or was disabling libgst.a
intentional?
I'm trying this all on Debian GNU/Linux (testing) w/ Linux 2.4.10,
GLibc 2.2.4, and GCC 2.95.4. This is with GST 1.95.4.
Thanks,
David Forster
- [Help-smalltalk] Embeding GST in an application,
David Forster <=