On Tue, Mar 8, 2011 at 10:30 AM, David Lichteblau <span dir="ltr"><<a href="mailto:david@lichteblau.com">david@lichteblau.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Quoting Elliott Slaughter (<a href="mailto:elliottslaughter@gmail.com">elliottslaughter@gmail.com</a>):<br>
</div><div class="im">> Undefined symbols:<br>
> "Smoke::classMap", referenced from:<br>
> Smoke::findClass(char const*)in commonqt.o<br>
> Smoke::findClass(char const*)in commonqt.o<br>
> "Smoke::NullModuleIndex", referenced from:<br>
> Smoke::idMethod(short, short)in commonqt.o<br>
> Smoke::idClass(char const*, bool)in commonqt.o<br>
> Smoke::idClass(char const*, bool)in commonqt.o<br>
> Smoke::idMethodName(char const*)in commonqt.o<br>
> Smoke::findClass(char const*)in commonqt.o<br>
> ld: symbol(s) not found<br>
> collect2: ld returned 1 exit status<br>
> make: *** [libcommonqt.1.0.0.dylib] Error 1<br>
<br>
</div>Just a shot in the dark, but I had a linking error on Windows, because<br>
CommonQt still links to smokeqtcore, and actually needs smokebase.<br>
<br>
Does it help if you change s/smokeqtcore/smokebase/ in <a href="http://commonqt.pro" target="_blank">commonqt.pro</a><br>
before re-running qmake?<br></blockquote></div><div><br></div><div>Yup, that fixed the link error.</div><div><br></div><div>I have a couple of quibbles about the way you load foreign libraries. The first is that you hard code the .so extension for non-unix platforms. Mac OS X uses a .darwin extension. Here's a minimal fix for that:</div>
<div><br></div><div><div>diff --git a/ffi.lisp b/ffi.lisp</div><div>index 36a4a99..0dd1fc0 100755</div><div>--- a/ffi.lisp</div><div>+++ b/ffi.lisp</div><div>@@ -34,10 +34,14 @@</div><div> </div><div> (defun load-libcommonqt ()</div>
<div> (cffi:load-foreign-library</div><div>- #-(or windows mswindows win32)</div><div>+ #-(or windows mswindows win32 darwin)</div><div> (namestring (merge-pathnames "libcommonqt.so"</div><div> (asdf::component-relative-pathname</div>
<div> (asdf:find-system :qt))))</div><div>+ #+(or darwin)</div><div>+ (namestring (merge-pathnames "libcommonqt.dylib"</div><div>+ (asdf::component-relative-pathname</div>
<div>+ (asdf:find-system :qt))))</div><div> #+(or windows mswindows win32)</div><div> (namestring (merge-pathnames "debug/commonqt.dll"</div><div> (asdf::component-relative-pathname</div>
<div>diff --git a/info.lisp b/info.lisp</div><div>index 6615e82..dcb9b52 100755</div><div>--- a/info.lisp</div><div>+++ b/info.lisp</div><div>@@ -696,7 +696,8 @@</div><div> #+debug (assert (< idx (length *module-table*)))</div>
<div> (cffi:load-foreign-library</div><div> (format nil</div><div>- #-(or mswindows windows win32) "libsmoke~A.so"</div><div>+ #-(or mswindows windows win32 darwin) "libsmoke~A.so"</div>
<div>+ #+(or darwin) "libsmoke~A.dylib"</div><div> #+(or mswindows windows win32) "smoke~A.dll"</div><div> name))</div><div> (let ((init (cffi:foreign-symbol-pointer</div>
</div><div><br></div><div>But beyond that basic issue, you don't take advantage of CFFI's *foreign-library-directories* feature, which is going to make it difficult for me to relocate the shared libraries. For example, if I wanted to save a core and distribute it as a binary, I don't think I'll be able to do that easily with this setup.</div>
<meta charset="utf-8"><div><br></div><div>For an example of how to do this look at lispbuilder-sdl's ffi code, especially around lines 9 and 27.</div><br><a href="http://code.google.com/p/lispbuilder/source/browse/trunk/lispbuilder-sdl/cffi/library.lisp">http://code.google.com/p/lispbuilder/source/browse/trunk/lispbuilder-sdl/cffi/library.lisp</a><br>
<div><br></div><div>At any rate, I can run the tutorial code, so thanks for the help :-).<br clear="all"><br>-- <br>Elliott Slaughter<br><br>"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay<br>
</div>