extend DLD to support loading Mac OS X frameworks
./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: *** [match.stamp] Error 139
(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 ()
Just to rule out the obvious can you try a build with CFLAGS=-g ?
I get the same results.
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.
So genbc is not 64-bit clean? /me scratches head :-)
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
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.
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…
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.
|Status:||active||» need info|
|Title:||Build failure on Mac OS X 10.6.1||» extend DLD to support loading Mac OS X frameworks|
|Category:||bug reports||» feature requests|
|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!
|Assigned to:||Unassigned||» bonzinip|
I'll rework loading of libraries in 3.3, and this will be fixed.
|Category:||feature requests||» bug reports|
This is still a problem on Mac OS X Yosemite. Compiling as 32 bit makes it work.