[Openmcl-devel] error linking OpenCV on osx
bennati at cognition.uni-freiburg.de
Mon Nov 19 04:44:33 CST 2012
Thank you all for your replies!
I followed Gary's suggestion and it worked! The problem was the graphics
not being visualised, and refreshed, in the main thread.
I know the cl-opencv and I find it really cool, but in my case is of no
use, because the existing library I'm using is written in C++.
On 11/16/12 3:42 PM, Gary Byers wrote:
> Someone who actually takes time to build the OpenCV libraries and their
> dependencies may reach a different conclusion. For all I know, that'd
> only take a few seconds, but I'd prefer to just make a guess ...
> On OSX, code that does "GUI things" (graphics, event processing, etc.)
> only works when it runs in the initial thread. It's the World's Most
> Advanced Operating System! (Yes, I know: saying that every few days
> hasn't made it any more reasonable, and I sometimes doubt that it will.)
> In CCL, the initial thread (the thread that's created by the OS when the
> application is run) ordinarily does some initialization, creates another
> thread to run the REPL, then spends most of its time sleeping. It wakes
> up a few times each second to do periodic "housekeeping" tasks, and wakes
> up again when QUIT is called (to shut down other threads and exit.)
> are a little different in the Cocoa IDE on OSX (the initial thread runs
> an event loop and another thread does "housekeeping"), but in almost all
> cases a listener thread isn't the initial thread.
> AFAIK, SBCL behaves differently (and the listener thread is ordinarily
> the initial thread.)
> Calling code from a listener thread - when that code only works
> correctly if it's called from the initial thread - only works correctly
> if the listener thread is the initial thread. Since that's ordinarily
> not true in CCL, that means that it's necessary to cause that code to
> run in the initial thread.
> Your example uses OPEN-SHARED-LIBRARY to ... open a few libraries, loads
> some lisp sources, then calls DO-CAPTURE (which, I assume, calls into the
> OpenCV library. Since some library initialization code on OSX executes
> illegal debugging instructions if it's run on a thread other than the
> initial thread - and since we can't expect a multibillion dollar company
> to do better than that - OPEN-SHARED-LIBRARY on OSX arranges to actually
> try to open the library on the initial thread.
> I don't know whether anything that happens when the .lisp files are
> calls into the foreign libraries; if so, those things need to be done in
> the initial process.
> The call to DO-CAPTURE likely does need to be done in the initial thread.
> One way to arrange for that to happen is to use
> (I believe that the intent was to export that symbol and document its
> but that doesn't seem to have happened.)
> (CCL::CALL-IN-INITIAL-PROCESS thunk)
> arranges for the initial thread/process to call the 0-argument
> function THUNK
> in the initial thread, waits for it to complete, and returns whatever
> THUNK returns. If I remember correctly, nothing especially useful
> if an error occurs during execution of THUNK, so you may want to do
> (multiple-value-bind (success error)
> (ccl::call-in-initial-process (lambda ()
> (ignore-errors (do-capture asd) t)))
> (unless success ...))
> That isn't absolutely horrible; it's probably harder to remember the
> need to
> deal with this issue than it is to actually deal with it.
> I think that the reasons that CCL does things the way that it does (runs
> the listener/REPL in a non-initial thread) are at least somewhat good
> they do cause people to run into problems like this, and I don't know
> those reasons are so compelling that we wouldn't want to consider doing
> it the other way. People would still have to be aware of these OSX
> limitations -
> (PROCESS-RUN-FUNCTION "background" (lambda () (do-capture ...))) would
> have the same problems, running under SLIME may also do so - but
> people who
> just want to use a foreign library wouldn't have to keep this in mind to
> the degree that they currently do.
> [Of course, this may be another problem entirely. If so, feel free to
> the above and wait until someone has time to build the library and
> the issue. Hmm. That might have taken less time than it took to
> write this
> On Fri, 16 Nov 2012, Stefano Bennati wrote:
>> Hallo everyone,
>> I write because I get a weird error while foreign-loading a C++
>> method that uses OpenCV on OSX.
>> Let's start from the beginning: I want to run from LISP a C++ library
>> that does some image processing.
>> I created a small example that shows an image on screen, then I used
>> SWIG to create the wrapper and compiled it into a shared library.
>> The weird thing is that the image is shown correctly in both Clozure
>> and SBCL on Linux, but on OSX it is shown only in SBCL... Clozure
>> shows a white rectangle instead.
>> It is really important for me to let it run under Clozure for OSX!
>> Any help will be really appreciated!
>> I attach a zip file with the example, there are two makefiles, one
>> for Linux and one for OSX (sed not working properly in the latter)
>> and four LISP loaders: two for SBCL, one for Linux and one for OSX
>> and 2 for CCL, one for Linux and one for OSX
>> M.Sc. Stefano Bennati
>> Centre for Cognitive Science
>> Friedrichstr. 50
>> D-79098 Freiburg, Germany
>> Phone: +49 761 203-4947
>> Fax: +49 761 203-4938
>> email: bennati at cognition.uni-freiburg.de
>> web: http://portal.uni.freiburg.de/cognition/members-de/bennati/
M.Sc. Stefano Bennati
Centre for Cognitive Science
D-79098 Freiburg, Germany
Phone: +49 761 203-4947
Fax: +49 761 203-4938
email: bennati at cognition.uni-freiburg.de
More information about the Openmcl-devel