Thread: [Clg-devel] CLG on Mac OSX
Brought to you by:
espen
From: Thomas D. <th...@de...> - 2006-08-26 09:10:02
|
Hi, I'm trying to install CLG on my Mac, under SBCL 0.9.16 (also tested on 0.9.14). In case it matters, I've got an Intel processor -- but I think this issue is probably a general OSX/Darwin problem. I'm using a recent checkout from the CLG CVS repository. I've updated asdf-extensions.lisp to understand library names ending in .dylib rather than .so, and also fixed a few hard-coded library names elsewhere in the lisp code. When linking alien.dylib, I get a linker error: /usr/bin/ld: Undefined symbols: _g_closure_add_finalize_notifier _g_closure_new_simple _g_closure_set_meta_marshal collect2: ld returned 1 exit status If I relink this against libgobject-2.0.dylib, all appears to be well until: debugger invoked on a UNDEFINED-FUNCTION: The function |g_value_get_type| is undefined. [...] (SB-KERNEL:%COERCE-CALLABLE-TO-FUN |g_value_get_type|) The problem is occurring while loading "gparam.fasl", offending line seems to be: (REGISTER-TYPE GVALUE |g_value_get_type|) Some simplistic poking around shows that load-dso has been called for libobject (and some other libraries) and appears to have completed successfully. So I'm confused as to why this function isn't visible. Then again, this is my first attempt at getting LISP and native code to play nicely together -- is there anything I should be trying? Thomas. |
From: Espen S J. <es...@cs...> - 2006-08-30 11:34:34
|
Thomas Down <th...@de...> writes: > I'm trying to install CLG on my Mac, under SBCL 0.9.16 (also tested > on 0.9.14). In case it matters, I've got an Intel processor -- but > I think this issue is probably a general OSX/Darwin problem. I'm using > a recent checkout from the CLG CVS repository. Thanks. Your feedback is very welcome. > I've updated asdf-extensions.lisp to understand library names ending > in .dylib rather than .so, and also fixed a few hard-coded library > names elsewhere in the lisp code. I have updated the code to not relay on hardcoded library extensions. > When linking alien.dylib, I get a linker error: > > /usr/bin/ld: Undefined symbols: > _g_closure_add_finalize_notifier > _g_closure_new_simple > _g_closure_set_meta_marshal > collect2: ld returned 1 exit status > > If I relink this against libgobject-2.0.dylib, It wasn't really necessary to call these functions from C so I have removed the code doing this. Although the problem may reappear later in the build process. > all appears to be well until: > > debugger invoked on a UNDEFINED-FUNCTION: > The function |g_value_get_type| is undefined. > [...] > (SB-KERNEL:%COERCE-CALLABLE-TO-FUN |g_value_get_type|) > > The problem is occurring while loading "gparam.fasl", offending line > seems to be: > > (REGISTER-TYPE GVALUE |g_value_get_type|) Until the long-awaited full introspection becomes available i GLib, clg uses nm to find all types in a library by searching for symbols ending with _get_type. The cause of the problem above is that nm doesn't take the same options in OSX as the GNU nm. I have checked in some untested code that may solve this. It would be nice if you could test it again and report back to the list. -- Espen |
From: Thomas D. <th...@de...> - 2006-08-30 17:49:09
|
Hi, and many thanks for your help. The OSX/Darwin version of nm prints out entries for undefined symbols, and doesn't seem to have any equivalent of the --defined-only option. (For example output, see http://www.derkholm.net/thomas/nm-example.txt -- let me know if you want to see output using different options). The undefined symbols are causing the loop in %find-types-in-library to terminate prematurely. There's also another issue: there's an extra '_' prepended to each symbol name. There's a little patch which solves these two issues below. Once this is applied, I can get much further through the build process. Unforturtunately, I don't quite have a working system yet: I'm getting the following while compiling the Cairo support: ; compiling (EXPORT-FROM-FILE #P"CLG:CAIRO;CAIRO.LISP") ; file: /Users/thomas/Software/clg/cairo/export.lisp ; in: EXPORT-FROM-FILE #P"CLG:CAIRO;CAIRO.LISP" ; (AUTOEXPORT:EXPORT-FROM-FILE #P"CLG:CAIRO;CAIRO.LISP") ; ; caught ERROR: ; (during macroexpansion of (EXPORT-FROM-FILE #P"CLG:CAIRO;CAIRO.LISP")) ; error opening #P"CLG:CAIRO;CAIRO.LISP.NEWEST": No such file or directory I'll keep investigating. Thomas. --- glib/gtype.lisp.orig 2006-08-30 18:15:11.000000000 +0100 +++ glib/gtype.lisp 2006-08-30 18:19:17.000000000 +0100 @@ -208,7 +208,8 @@ (run-program "/usr/bin/nm" #+clisp :arguments - (list #-darwin"--defined-only" #-darwin"-D" "-g" #+darwin"-f" (namestring (truename pathname))) + (list #-darwin"--defined-only" #-darwin"-D" "-g" #+darwin"-f" #+darwin"-s" + #+darwin"__TEXT" #+darwin"__text" (namestring (truename pathname))) :output :stream :wait nil))) (unwind-protect (loop @@ -219,7 +220,7 @@ nil)) (pos (position #\Space line :from-end t))) (when (and line #+darwin(char= (char line (1- pos)) #\T)) - (subseq line (1+ pos)))) + (subseq line #-darwin(1+ pos) #+darwin(+ pos 2)))) while symbol when (and (> (length symbol) 9) On Wed, Aug 30, 2006 at 01:34:24PM +0200, Espen S Johnsen wrote: > Thomas Down <th...@de...> writes: > > > I'm trying to install CLG on my Mac, under SBCL 0.9.16 (also tested > > on 0.9.14). In case it matters, I've got an Intel processor -- but > > I think this issue is probably a general OSX/Darwin problem. I'm using > > a recent checkout from the CLG CVS repository. > > Thanks. Your feedback is very welcome. > > > > I've updated asdf-extensions.lisp to understand library names ending > > in .dylib rather than .so, and also fixed a few hard-coded library > > names elsewhere in the lisp code. > > I have updated the code to not relay on hardcoded library extensions. > > > When linking alien.dylib, I get a linker error: > > > > /usr/bin/ld: Undefined symbols: > > _g_closure_add_finalize_notifier > > _g_closure_new_simple > > _g_closure_set_meta_marshal > > collect2: ld returned 1 exit status > > > > If I relink this against libgobject-2.0.dylib, > > It wasn't really necessary to call these functions from C so I have > removed the code doing this. Although the problem may reappear later in > the build process. > > > all appears to be well until: > > > > debugger invoked on a UNDEFINED-FUNCTION: > > The function |g_value_get_type| is undefined. > > [...] > > (SB-KERNEL:%COERCE-CALLABLE-TO-FUN |g_value_get_type|) > > > > The problem is occurring while loading "gparam.fasl", offending line > > seems to be: > > > > (REGISTER-TYPE GVALUE |g_value_get_type|) > > Until the long-awaited full introspection becomes available i GLib, clg > uses nm to find all types in a library by searching for symbols ending > with _get_type. The cause of the problem above is that nm doesn't take > the same options in OSX as the GNU nm. I have checked in some untested > code that may solve this. It would be nice if you could test it again > and report back to the list. > > -- > Espen |
From: Thomas D. <th...@de...> - 2006-08-30 19:15:29
|
On Wed, Aug 30, 2006 at 06:48:48PM +0100, Thomas Down wrote: > ; caught ERROR: > ; (during macroexpansion of (EXPORT-FROM-FILE #P"CLG:CAIRO;CAIRO.LISP")) > ; error opening #P"CLG:CAIRO;CAIRO.LISP.NEWEST": No such file or directory Okay, scratch that, it was just a stupid error when setting up logical-pathname-translations. I can now compile CLG under OSX. There are a couple more minor issues I've caught: - In gtkobject.lisp, there's on remaining hardcoded ".so" - Under OSX, gtk/alient.dylib needs to be linked with libgtk and libgobject With these two issues resolved, everything compiles, and (load "hello-world") opens a window. I'm still running into a snag once it tries to render some text: WARNING: Pango: `script_engine_init': dlsym(3) failed Failed to load Pango module for id: 'BasicScriptEngineFc' [repeated several times...] Pango: _pango_cairo_font_map_get_renderer: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed I'm wondering if this might be a Pango-on-OSX issue, though: CLG itself appears to be doing its job. Thanks for helping out with this issue, Thomas. |
From: Espen S J. <es...@cs...> - 2006-08-31 10:22:35
|
Thomas Down <th...@de...> writes: > The OSX/Darwin version of nm prints out entries for undefined > symbols, and doesn't seem to have any equivalent of the > --defined-only option. (For example output, see > http://www.derkholm.net/thomas/nm-example.txt -- let me know > if you want to see output using different options). The undefined > symbols are causing the loop in %find-types-in-library to > terminate prematurely. There's also another issue: there's an > extra '_' prepended to each symbol name. There's a little patch > which solves these two issues below. Thanks, I've applied your patch and also fixed my mistake in the loop (but I guess it isn't really necessary to check for lines with a 'T' when the -s option is given to nm). > There are a couple more minor issues I've caught: > > - In gtkobject.lisp, there's on remaining hardcoded ".so" Fixed > - Under OSX, gtk/alient.dylib needs to be linked with > libgtk and libgobject I've added a :ldflags option to the unix-dso component and updated gtk.asd with the required linker flags. > With these two issues resolved, everything compiles, and > (load "hello-world") opens a window. I'm still running into > a snag once it tries to render some text: > > WARNING: Pango: `script_engine_init': dlsym(3) failed > Failed to load Pango module for id: 'BasicScriptEngineFc' > [repeated several times...] > Pango: _pango_cairo_font_map_get_renderer: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed > > I'm wondering if this might be a Pango-on-OSX issue, though: > CLG itself appears to be doing its job. I don't know what could cause this error, but I noticed that there is a tool called pango-querymodules and that its man page mention something about a 'Pango module path'. -- Espen |
From: Thomas D. <th...@de...> - 2006-08-31 19:59:02
|
On Thu, Aug 31, 2006 at 12:22:27PM +0200, Espen S Johnsen wrote: > > WARNING: Pango: `script_engine_init': dlsym(3) failed > > Failed to load Pango module for id: 'BasicScriptEngineFc' > > [repeated several times...] > > Pango: _pango_cairo_font_map_get_renderer: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed > > > > I'm wondering if this might be a Pango-on-OSX issue, though: > > CLG itself appears to be doing its job. > > I don't know what could cause this error, but I noticed that there is a > tool called pango-querymodules and that its man page mention something > about a 'Pango module path'. Yes, pango-querymodule runs fine, and detects all the installed pango modules. I can also run pango-view, and other GTK applications. Since the problem seems to occur when Pango tries to load its modules, I've rebuild Pango as a single shared library, with all the modules statically linked in (using the --with-included-modules option when configuring Pango). The new static Pango now works fine under CLG. I guess this suggests there's some kind of problem under OSX/Darwin when using dlopen/dlsym from within a library which was itself opened using dlopen. When running the CLG examples, I also ran into a very similar problem with GDK refusing to load its image-decoding modules. Once again the solution is to build these modules into the main library (./configure --disable-modules --with-included-loaders). Having done this, CLG is running very nicely on my Mac: http://www.derkholm.net/thomas/success.png I guess I should poke around in the OSX linker documentation to find out why the module loading isn't working. Thomas |
From: Espen S J. <es...@cs...> - 2006-08-31 20:40:01
|
Thomas Down <th...@de...> writes: > When running the CLG examples, I also ran into a very similar problem > with GDK refusing to load its image-decoding modules. Once again > the solution is to build these modules into the main library > (./configure --disable-modules --with-included-loaders). Having > done this, CLG is running very nicely on my Mac: > > http://www.derkholm.net/thomas/success.png > > I guess I should poke around in the OSX linker documentation > to find out why the module loading isn't working. Looks nice :-) I hope you find some solution to this problem. -- Espen |