Package Details: flann 1.9.1-7

Git Clone URL: https://aur.archlinux.org/flann.git (read-only, click to copy)
Package Base: flann
Description: FLANN is a library for performing fast approximate nearest neighbor searches in high dimensional spaces
Upstream URL: https://github.com/mariusmuja/flann
Licenses: BSD
Submitter: None
Maintainer: acxz
Last Packager: acxz
Votes: 41
Popularity: 0.000387
First Submitted: 2011-04-05 02:06
Last Updated: 2020-04-19 05:05

Dependencies (7)

Required by (12)

Sources (1)

Pinned Comments

acxz commented on 2020-02-03 02:07

Development is on Github: https://github.com/acxz/pkgbuilds Please open issues and PRs there instead of commenting.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

racko commented on 2018-03-06 21:49

Fixed. I messed up the library order in the target_link_libraries call. The linker would think that lz4 is unneeded. Since "--as-needed" is included in LDFLAGS in the default /etc/makepkg.conf, lz4 was removed.

I removed "--as-needed" a long time ago because some other AUR package messed up, so the error didn't occur on my main machine.

Thanks for bringing up the issue again.

racko commented on 2018-03-06 06:27

Hmm ... I can reproduce this now as well.

Even after building with make VERBOSE=1 and seeing (note -llz4)

c++ -fPIC -march=native -O3 -pipe -fstack-protector-strong -fopenmp -O3 -DNDEBUG -Wl,-O1,--sort-common,--as-needed,-z,relro -shared -Wl,-soname,libflann.so.1.9 -o ../../lib/libflann.so.1.9.1  -llz4 -Wl,-whole-archive ../../lib/libflann_s.a -Wl,-no-whole-archive

the resulting libflann.so still does not list an lz4 dependency :(

I am looking into it.

subhuman22 commented on 2018-03-06 03:20

The resulting libflann.so still omits dependency on system liblz4

    $ ldd /usr/lib/libflann.so

    linux-vdso.so.1 (0x00007ffe6fdf5000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f0554eb1000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f0554b65000)
    libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f0554937000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f0554720000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f0554369000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x00007f0555978000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f0554165000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f0553f47000)

As a temporary fix, you can just use src/cpp/ext/lz4... by removing patch lines in PKGBUILD. Not sure this can be a problem in the future.

racko commented on 2018-01-29 18:46

Thanks, fixed.

lukaszmoroz commented on 2018-01-28 23:49

I needed texlive-core to make this package.

justbuchanan commented on 2018-01-18 05:49

I ran into an lz4 issue when linking against flann from a library built through cmake. If I add target_link_libraries(mylib lz4) to my cmake, everything works again. Here's the error message:

undefined reference to symbol 'LZ4_decompress_safe_continue'
/usr/lib/liblz4.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

I used ldd to inspect the library deps of flann and here's what I see. Neither library shows a dependency on liblz4.

$ ldd /usr/lib/libflann_cpp.so           
linux-vdso.so.1 (0x00007ffda0370000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f398c423000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f398c205000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f398be4e000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f398bb02000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f398c9ac000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f398b8eb000)
$ ldd /usr/lib/libflann.so           
linux-vdso.so.1 (0x00007fff4adce000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f5b4186a000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f5b4151e000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f5b412f0000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f5b410d9000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f5b40d22000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f5b4232a000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f5b40b1e000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f5b40900000)

I see the patch file that links against the system's lz4 and it looks right as far as I can tell. Any thoughts?

note: I'm using version 1.9.1-1 of this pkgbuild.

racko commented on 2018-01-10 21:39

@kartikmohta: I followed your suggestion and made flann use the system's lz4. I did not change flann's version number to minimize issues for other users in case I did something wrong. Could you please give it a try?

(I also cleaned up the PKGBUILD a bit more.)

racko commented on 2018-01-10 05:33

I'll look into it today.

kartikmohta commented on 2018-01-09 21:20

flann since v1.8.5 includes a local copy of the lz4 library (in src/cpp/ext). The version included is 1.7.1 while the system version in Arch is 1.8.0. This causes problems in an application using both flann and lz4 due to some API changes in the upstream lz4. I get the following error:

In file included from /usr/include/flann/flann.hpp:41:
In file included from /usr/include/flann/util/matrix.h:35:
In file included from /usr/include/flann/util/serialization.h:9:
/usr/include/flann/ext/lz4.h:249:72: error: typedef redefinition with different types ('struct LZ4_streamDecode_t' vs 'union LZ4_streamDecode_u')
typedef struct { unsigned long long table[LZ4_STREAMDECODESIZE_U64]; } LZ4_streamDecode_t;
                                                                       ^
/usr/include/lz4.h:280:34: note: previous definition is here
typedef union LZ4_streamDecode_u LZ4_streamDecode_t;   /* incomplete type (defined later) */

This can be avoided by using the system version of lz4 in flann but that requires quite a few changes in the src/cpp/CMakeLists.txt. There is an issue on github reporting this https://github.com/mariusmuja/flann/issues/307 but it hasn't got any replies.

racko commented on 2018-01-05 14:49

I did my best. Here are some notes regarding the update to version 1.9.1-1:

- Added -DBUILD_TESTS=OFF to cmake options because there was no check()
  anyhow
- removed flann-1.8.4-gcc6.patch, since the issue has been fixed
  upstream
- removed the lib64 -> lib sed call because it is not necessary anymore
- removed the sed calls for the *.cu files because we do not compile the
cuda lib
- Attempted to add a check() function, but the "LshIndex_*" tests are
known to fail: <https://github.com/mariusmuja/flann/issues/316>
- Attempted to enable BUILD_CUDA_LIB=ON but thrust::gather, used in
kdtree_cuda_3d_index.cu, has been removed in Thrust v1.4.0 (current is
1.9)