Fix for LabRecorder in OSX

[GoogleCodeExporter]

With recent changes, lsl now compiles in OSX. I've attached the new .dylib for 
those that would like to save the effort of compiling it themselves.

See issue #27 for modifications to pylsl.py for the necessary changes to 
pylsl.py
https://code.google.com/p/labstreaminglayer/issues/detail?id=27

I attached a makefile for RecorderLib in osx. To use it, change to the 
LabRecorder\src\RecorderLib\RecorderLib directory and run
`make --makefile=makefile.osx`

Or just use my RecorderLib64.dylib, attached.

I had to make a tiny change to LabRecorder.py to get it to work. The diff is 
attached.

Place RecorderLib64.dylib in the same directory as LabRecorder.py
`python LabRecorder.py`

It works!

Original issue reported on code.google.com by chadwick...@gmail.com on 3 Mar 2015 at 10:03

Attachments:

• liblsl64.dylib
• makefile.osx
• RecorderLib64.dylib
• LabRecorder.diff

[GoogleCodeExporter]

Do you recall if previously you had to hand-tweak swig's output (e.g., .py 
_wrap.cxx) when swigging RecorderLib? I ask because I re-swigged and 
re-compiled (OSX- and linux-compatible makefile attached), and was able to 
generate _RecorderLib.so, and import it, but I couldn't use it because I kept 
getting TypeError on the second argument (void **recordfrom) to 
rl_start_recording. It might be necessary to specify a typemap in the .i file, 
or I think you can also get around it if you tweak swig's output files, hence 
the question.

Using the attached makefile, the output can be imported with the generated 
RecorderLib.py file using
import RecorderLib as recorder_lib

The shared object has to be named _RecorderLib.so in OSX and linux, or 
_RecorderLib.pyd in Windows.

Original comment by chadwick...@gmail.com on 5 Mar 2015 at 7:22

Attachments:

• makefile.swig

[GoogleCodeExporter]

I also attempted with ctypes. I attached RecorderLib.py and the makefile to 
generate the (non-swig non-python) RecorderLib64.dylib or .so

Put RecorderLib.py and the generated library in the same folder as 
LabRecorder.py. Modify LabRecorder.py to get rid of all the library searching 
and simply
import RecorderLib as recorder_lib

Using this I can record just fine, but it still generates the segfault when 
closing the recording.

While it doesn't fix the problem, it does allow us to take SWIG out of the 
equation.

Original comment by chadwick...@gmail.com on 5 Mar 2015 at 7:28

Attachments:

• makefile
• RecorderLib.py

[GoogleCodeExporter]

OK I got it.

In LabRecorder.py, add "cast" to the list of names imported from ctypes
Then, change
recorder_lib.rl_end_recording(self.CurrentRecording)
to
recorder_lib.rl_end_recording(cast(self.CurrentRecording, c_void_p))

The file gets its footer written and the GUI doesn't crash.

I still get a crash when I click on the GUI's close button, with this error in 
console:
Illegal instruction: 4

But I'm not too concerned about that at the moment.

Original comment by chadwick...@gmail.com on 5 Mar 2015 at 7:44

[GoogleCodeExporter]

A little more information about the crash when clicking on close. This time I 
got the following error:

Assertion failed: (!posix::pthread_mutex_destroy(&m)), function ~mutex, file 
/absolute/path/to/labstreaminglayer/LSL/liblsl/external/lslboost/thread/pthread/
mutex.hpp, line 108.
Abort trap: 6

Original comment by chadwick...@gmail.com on 6 Mar 2015 at 3:31

[GoogleCodeExporter]

This is unrelated to the crash, but...

I am trying to make a CMakeLists.txt file for RecorderLib. I got something that 
generates a dylib, but it segfaults when used. I managed to get rid of all of 
the differences in the commands generated by CMake and those generated by my 
non-segfaulting makefile, except for the following two flags added by CMake to 
the linker command:
-Wl,-headerpad_max_install_names
-install_name /absolute/path/to/dylib

I'm not sure why this would cause the segfault. However, something that seems 
to pop up when searching for CMake and segfault is when using homebrew Python, 
the dylib might be linking against system Python even when the interpreter is 
homebrew Python.

Original comment by chadwick...@gmail.com on 6 Mar 2015 at 3:03

[GoogleCodeExporter]

The problem was that CMake was finding the very old system (/usr/local/ib) 
liblsl64.dylib that I had made a long time ago. It turns out that CMake doesn't 
really respect the link_directories command, you have to specify the path to 
the library in the target_link_libraries command.

I discovered the problem by using otool -L RecorderLib64.dylib on both the 
working one and non-working one and seeing the difference.

Anyway, here is a CMakeLists.txt that works for OSX. I'll see if I can get it 
working in Windows.

Original comment by chadwick...@gmail.com on 6 Mar 2015 at 3:30

Attachments:

• CMakeLists.txt

[GoogleCodeExporter]

So I have realized that the fixes to pylsl.py to make it compatible with Mac 
has caused LabRecorder to be rather buggy on Windows and Linux -- i.e. it will 
sometimes crash on exit and always if recording is restarted.

This will get fixed, but for the time being I have reverted pylsl.py to its 
former glory. There is still a copy which has Chad's fixes in them in the 
LabRecorder src folder. It's called pylsl-mac-exp.py.

This information is also in the latest log.

Original comment by david.er...@gmail.com on 16 Mar 2015 at 10:25