CODEWITHSUNDEEP
matlabcompilationldmexopenni
noio
noio

Reputation: 5812

gcc linker can't find library (openNI)

Can anybody give me some hints for solving this?

I'm trying to compile "Kinect Matlab" (on Mac OS 10.7), in the compile script is the following line:

mex('-v','-L/usr/lib/','-lOpenNI',[...],Filename);

This is the full command run by mex: (1)

gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2011a.app/extern/lib/maci64/mexFunction.map -o  "mxNiChangeDepthViewPoint.mexmaci64"  mxNiChangeDepthViewPoint.o  -L/usr/lib/ -lOpenNI -L/Applications/MATLAB_R2011a.app/bin/maci64 -lmx -lmex -lmat -lstdc++

Then I'm getting the following error:

ld: library not found for -lOpenNI
collect2: ld returned 1 exit status

    mex: link of ' "mxNiChangeDepthViewPoint.mexmaci64"' failed.

There is most definitely a file at /usr/lib/libOpenNI.dylib.

What kinds of things cause ld to throw this error?

What I tried:

Env vars:

I've tried to add the library to the environment variables using the following command, from the matlab terminal. No effect.

setenv('DYLD_LIBRARY_PATH', [getenv('DYLD_LIBRARY_PATH') ':/usr/lib/']);

In bash:

Just calling gcc as suggested here https://serverfault.com/questions/54736/how-to-check-if-a-library-is-installed gives no problems.

$ gcc -lOpenNi
Undefined symbols for architecture x86_64:
  "_main", referenced from:
      start in crt1.10.6.o

However, if I run g++ first, then gcc as in (1), same error as before. (library not found). How come gcc can find the library, but when matlab adds the stuff in (1) it messes things up?

So, related to what is said above, I started removing all arguments from (1) until I got a different error. I removed the -Wl,-syslibroot, meaning that -syslibroot would no longer be passed to ld, this seems to have fixed it. So -syslibroot is messing up the library search directory! Now to find a way to remove this argument from the mex() call.

Upvotes: 3

Views: 2515

Answers (3)

noio
noio

Reputation: 5812

BOOM! IT WORKS!

Okay, here it is:

The -Wl,-syslibroot option in the gcc call (1) is sending a -syslibroot option to the linker, and somehow that gets prepended to the library search path (even though it shouldn't according to cannot specify root sdk directory with syslibroot when linking)

So, removing this -syslibroot can solve our problem, this can be done in mexopts.sh. Copying matlab's version from the default location:

cp /Applications/MATLAB_R2011a.app/bin/mexopts.sh ~/.matlab/R2011a/

And then changing this line (201):

LDFLAGS="-Wl,-twolevel_namespace -undefined error -arch $ARCHS -Wl,-syslibroot,$SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET"

Removing the -Wl,-syslibroot,$SDKROOT argument.

Additionally, I could remove the -L/usr/lib argument from the call to mex, making it simply:

 mex('-v','-lOpenNI',['-I' OpenNiPathInclude],Filename);

Upvotes: 0

gsbabil
gsbabil

Reputation: 7703

Did you trying adding OpenNi to your LIBRARY_PATH ?

export LIBRARY_PATH=$LIBRARY_PATH:/YOUR-PATH/OpenNi

Upvotes: 2

jmkeyes
jmkeyes

Reputation: 3771

First option: if libOpenNi isn't of the same architecture as the binary you're compiling, the whole compiler suite will likely ignore it. If you did manage to get it to link anyway, it would probably crash. Find a native 64 bit library and link against that.

Second option: I'm not 100% sure on this, but whenever I've tried doing linking on some esoteric linux projects, I start with a .a object archive in the path specified by -L. If it links, then I'll add -fPIC -shared on x86_64 to get it to compile against the shared library. I'm not sure if this will work on OSX: I've never done development on that platform yet.

Upvotes: 1

Related Questions