2

I hope this question is not to specific. I am trying to compile the vlfeat library for octave 3.6.2.

It compiles the mex-files without errors. But if I execute

vl_setup
vl_demo

i get 

error: vl_demo_sift_basic: vl_sift.mex: failed to load: vl_sift.mex: undefined symbol: vl_sift_process_next_octave

If I use octave 3.4.3 instead, the mex file loads without errors. (But there are other errors later because of matlab functions which are not implemented yet in this version of octave.)

I have no idea how I could start investigating this problem. What could be the reason for such an error message? Or what can I do to further investigate this problem?

Update: I did some more research. But I am not very familiar with the process of linking and compiling.

Using ldd I can see that the vlfeat shared library does not show up in the list. Using nm the symbols appear as 'U' for undefined. But I think the library should be linked. The problem is with all the mex files. Here is one example of how the files are compiled. As far as I can see, the library is linked to the mex-file.

CFLAGS="-std=c99 -Wall -Wextra -Wno-unused-function -Wno-long-long -Wno-variadic-macros    -DNDEBUG -O3  -I./toolbox" \
CXXFLAGS="" \
LDFLAGS=" -Wl,--rpath,\$ORIGIN/ -Wl,--as-needed -lpthread -lm -Lbin/glnxa64 -lvl" \
 mkoctfile \
       --mex  \
       "./toolbox/misc/vl_version.c" --output "toolbox/mex/octave/vl_version.mex"
sietschie
  • 7,425
  • 3
  • 33
  • 54

3 Answers3

4

I met same problem. The following works:

  1. Make sure that missing symbol "vl_sift_process_next_octave exists" in vlfeat dynamic library - libvl.so - by "nm libvl.so | grep vl_sift_process_next_octave". If it is not the case, you shoud rebuld vlfeat.

  2. If it does, check that annoying mex file vl_sift.mex refers libvl.so correctly by "readelf -d vl_sift.mex". There appear libvl.so entry in dynamic section or rebuild mex file specifying explicitly missing so by "mkoctfile --mex -lvl ...".

  3. Now a final step is left. The "libvl.so" should be visible to octave. Use ldconfig to add libvl.so into so cache and test whether it exists in the cache by "ldconfig -p | grep libvl.so". That is all.

hkyi
  • 3,516
  • 2
  • 19
  • 9
  • Thank you for your answer. I am struggling a little bit with step 3. I do not have root access on my machine. So I think I can't use `ldconfig`. I tried using `LD_LIBRARY_PATH` without success. I am now using `LD_PRELOAD`. Now I am able to run some of the demos. Do you know a way to make it more permanent? Maybe something that can be added to .bashrc or something? – sietschie Feb 19 '13 at 17:02
  • And just for the record: Step 1 was not my problem. But it seems that the symptoms of 2. are caused by the fact, that `mkoctfile` does not pass the `LDFLAGS` to the linker. I fixed it for me by changing the Makefile so that the flags are passed directly to the `mkoctfile` which then passes them correctly to the linker. – sietschie Feb 19 '13 at 17:07
1

I also had the same problem, using Octave 3.6.2 and vlfeat 0.9.16. Checked octave.mak and noticed that OCTAVE_MEX_FLAGS is empty and that OCTAVE_MEX_LDFLAGS is never used. So, in the section octave-mex-all, I tried changing OCTAVE_MEX_FLAGS with OCTAVE_MEX_LDFLAGS . That is, I used: 

 $(MKOCTFILE) \
       --mex $(OCTAVE_MEX_LDFLAGS) \
       "$(<)" --output "$(@)"
@rm -f $(<:.c=.o)

I then rebuilt with make all, and things now work. But I did not try to investigate further why it is so.

Hope this helps

user2105434
  • 11
  • 1
1

In case somebody bumps into this thread in the future, the problem persists in Octave 4.0.0. Changing the make/octave.mak before compiling the library as suggested in here solved my issue: https://github.com/vlfeat/vlfeat/issues/18. Instead of OCTAVE_MEX_FLAGS, OCTAVE_MEX_LDFLAGS should be set.

# Linux on 32 bit processor
ifeq ($(ARCH),glnx86)
OCTAVE_MEX_LDFLAGS += -Wl,--rpath,\\\$$ORIGIN/
endif

# Linux on 64 bit processorm
ifeq ($(ARCH),glnxa64)
OCTAVE_MEX_LDFLAGS += -Wl,--rpath,\\\$$ORIGIN/
endif
Copper
  • 121
  • 1
  • 2