Home » Projects » GNU Smalltalk » Issues

extend DLD to support loading Mac OS X frameworks

By Damien Pollet - Posted on September 30th, 2009
Tagged:
Project:GNU Smalltalk
Component:VM
Category:feature
Priority:minor
Assigned:bonzinip
Status:active
Description

I get 

./genbc ./byte.def ./byte.c ./opt.c ./xlat.c > match.h
/bin/sh: line 1: 60172 Segmentation fault      ./genbc ./byte.def ./byte.c ./opt.c ./xlat.c > _match.h
make[2]: *** [match.stamp] Error 139

gdb says 

(gdb) run byte.def byte.c opt.c xlat.c
Starting program: /opt/local/var/macports/build/_Users_damien_var_macports_lang_gst-dev/work/gst-dev-1.0/libgst/genbc byte.def byte.c opt.c xlat.c
Reading symbols for shared libraries +. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000007e
0x000000010000b2c7 in avl_rebalance ()

Updates

#1 submitted by Paolo Bonzini on Wed, 09/30/2009 - 14:16

Just to rule out the obvious can you try a build with CFLAGS=-g ?

Thanks.

#2 submitted by Damien Pollet on Wed, 09/30/2009 - 15:19

I get the same results.

#3 submitted by Eli Green on Tue, 10/13/2009 - 13:35

By default, Mac OS 10.6's compilers will try to produce 64-bit executables and genbc doesn't work. You can successfully build if you're willing to generate 32-bit executables as per the instructions on the wiki: http://smalltalk.gnu.org/node/223

If you're not interested in any of the Gtk stuff, you can simply configure it with this command:
MAKE=gnumake CFLAGS='-m32' LDFLAGS='-arch i386' ./configure

I recommend building with gnumake, not make. If you want Gtk stuff, check the wiki.

#4 submitted by Paolo Bonzini on Tue, 10/13/2009 - 13:41

So genbc is not 64-bit clean? /me scratches head :-)

#5 submitted by Alexey Zakhlestin on Sat, 10/17/2009 - 19:27

Looks like it's a fault of libsigsegv, actually.

building it works just fine, but "make check" reports failure of all tests in 64-bit mote

#6 submitted by Eli Green on Sat, 10/17/2009 - 19:46

Are you certain? genbc never worked for me when compiled as 64-bit. However, if match.h had already been generated from a previous build, it could have skipped the genbc step. Maybe there's a difference in bytecodes between 32 and 64-bit VMs And your match.h has been generated with the 32-bit versions?

Paolo; the errors that I had found with genbc were in the avltrees code but I didn't get a chance to hunt them down.

#7 submitted by Damien Pollet on Wed, 11/04/2009 - 17:49

OK, I think I'll give up with the macports package…
I tried the "From source" method with GTK+ OSX. I get a working gst, but the Cairo package does not get built (I don't have Cairo.star).

From config.log, pkg-config and gawk gnumake are found/used, all paths to add to PKG_CONFIG_PATH seem ok, but libcairo is not found.
I tried adding -L/Library/Frameworks/Cairo.framework/Libraries to LDFLAGS, but I suspect that's redundant with pkginfo…

#8 submitted by Paolo Bonzini on Wed, 11/04/2009 - 21:57

Cairo is now sought with pkg-config. I'm not sure it will work to use the Cairo bindings directly, because those just do dlopen("libcairo"), but it should be enough when the GTK package is also loaded.

#9 submitted by Paolo Bonzini on Wed, 11/04/2009 - 21:59
Status:active» need info
#10 submitted by Paolo Bonzini on Thu, 11/05/2009 - 11:13
Title:Build failure on Mac OS X 10.6.1» extend DLD to support loading Mac OS X frameworks
Category:bug reports» feature requests
Priority:normal» minor
Status:need info» active

To get the cairo bindings to work without loading GTK, lt_dlopen would need to support loading Mac OS X frameworks.

However, it's cool that you got everything to work!

#11 submitted by Paolo Bonzini on Wed, 03/09/2011 - 11:42
Component:Build» VM
Assigned to:Unassigned» bonzinip

I'll rework loading of libraries in 3.3, and this will be fixed.

User login