SDK install on Mac OSX Mavericks fails (incorrect compiler flags in liblo?)


I’m trying to install the prerequisites on Mac OSX, following the guidelines here:

I’ve picked up the source of liblo (version 0.28) and am trying to build it.

However, ./configure fails with an error which essentially is caused by the autoconf script trying to build a MacOSX bundle file that cannot be executed.

The error in config.log is:
[SIZE=11px]./configure: line 3671: ./conftest: cannot execute binary file[/SIZE]

which is caused by the ./conftest binary being non-executable. The ./conftest binary is built with this command line:
[SIZE=11px]gcc -o conftest -arch i386 -arch x86_64 -Wall -undefined dynamic_lookup -bundle -arch i386 -arch x86_64 conftest.c[/SIZE]

If I try to build the conftest.c file manually REMOVING the -bundle option, it builds and runs correctly, as expected.

Probably the -bundle option should not have been there in the first place, but I’m not sure why it’s there or how to get rid of it…

I know this is an issue with liblo, but since it’s prescribed NOT to use a prebuilt (macports) version for some non-specified reason, it looks like I need to get this running :frowning:

Has anyone been able to get this running? Or are the linked instructions simply incorrect/not updated?


Turned out the liblo didn’t like my usual multi-arch build environment, so with some tweaking it got to compile. Now onto the next set of packages that don’t want to install :slight_smile:


Well… testing out muse-lab now on MacOS, and I’m assuming I need to run first muse-io in order to connect to the device.

According to it “should already be in my path” – which it isn’t, as /Applications/Muse is not automatically added to my path (nor should it be).

Anyway, when trying to run /Applications/Muse/muse-io, it complains like this:
[SIZE=11px]dyld: Library not loaded: /Users/narek/Dev/3rdparty/lsl/build/LSL/liblsl/src/liblsl.dylib[/SIZE]
[SIZE=11px] Referenced from: /Applications/Muse/muse-io[/SIZE]
[SIZE=11px] Reason: image not found[/SIZE]
[SIZE=11px]Trace/BPT trap: 5[/SIZE]

… so unless I’m mistaken (which I could be!) it looks like the library name is hardcoded and required to exists in user “narek” home directory. At least, “otool -L /Applications/Muse/muse-io” reveals such a dependency. Incidentally, the library has no version number/compatibility listed – this might be a good idea to add for future releases too.

Since files in that directory, for obvious reasons, are not accessible from my machine, I’d prefer it to access the library that has kindly been bundled in /Applications/Muse/liblsl.dylip instead :slight_smile:

Anyway I could do that easily?

If not, I guess I’m OOL at this point, and short of patching the binary files I probably need to await another release of the SDK?


You need to set the dyld_library_path env variable to [SIZE=11px]/Applications/Muse “export [/SIZE]dyld_library_path=[SIZE=11px]/Applications/Muse”. The hardcoded path is what it reverts to when the dyld isn’t found. We would build more statically but we assume the preferred interpretation of the foss liscense is for us to dynamically link to foss code.[/SIZE]


Thanks, Matt!

You’re partly correct… :slight_smile: Turns out it’s actually (capital letters):
export DYLD_LIBRARY_PATH=/Applications/Muse

It still makes absolutely no sense to have some developer’s private home directory path embedded in the binary; that is never going to be correct for anyone else. So you might want to consider setting the hardcoded path to refer to the one in /Applications/Muse/… which means it would work for the default installation.

It might also be a good idea to put this vital piece of information in the tutorial ( In there it says the binary is added to your path (it isn’t and shouldn’t be, of course) and also it mentions nothing of the DYLD problem.

As for “FOSS license”, I guess you’re referring to the use of GPL’ed code, not FOSS in general? If so, this is what gnu says about the two license: [I]Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)[/I] [I]No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?[/I]
[I]Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)[/I] [I]For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):[/I]
[INDENT] I If you statically link against an LGPL’d library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.[/I]
I If you dynamically link against an LGPL’d library already present on the user’s computer, you need not convey the library’s source. On the other hand, if you yourself convey the executable LGPL’d library along with your application, whether linked with statically or dynamically, you must also convey the library’s sources, in one of the ways for which the LGPL provides.[/I]
[/INDENT] So if you’re using LGPL code and would have linked it statically, you need to provide a linkable object format. If you link dynamically, you don’t need to. In both cases you’d need to provide the library source (as you distribute the library). If you’re using GPL code, there is no difference whether you link statically or dynamically…

So I guess you’re using LGPL code also – even though it looks like the particular library in question (lsl) might actually be covered my an MIT licence, in which case it probably makes no difference how you link.

Anyway, sorry for the digression and thanks for your reply,

– Per.