Package Details: bear 3.0.7-1

Git Clone URL: (read-only, click to copy)
Package Base: bear
Description: tool to generate compilation database for clang tooling
Upstream URL:
Licenses: GPL3
Conflicts: bear, interception-tools
Provides: bear
Submitter: mlq
Maintainer: xythrez
Last Packager: xythrez
Votes: 42
Popularity: 1.76
First Submitted: 2013-07-08 09:40
Last Updated: 2021-01-16 19:42

Latest Comments

1 2 Next › Last »

Joe_Schmo commented on 2020-12-26 03:56

Hi xythrez, it seems your package conflicts with the interception-tools. Specifically, both use the directory "/usr/bin/intercept." To recreate, just install both and you should get an error saying:

bear: /usr/bin/intercept exists in filesystem (owned by interception-tools)

I sent a similar message to the maintainer of the other package as well! Hopefully this is the place to put this sort of problem.

Edit: interception-tools has since been moved to the community repository

xythrez commented on 2020-10-28 21:17

@Xoepe, Can you provide more details? I just tried compiling on a clean install and it works as expected. Can you see if its possible to compile the code per the instructions on GitHub?

Xoepe commented on 2020-10-28 18:48

This is failing to build. It just finished building citnames_a and it outputs the following:

make[3]: *** [Makefile:160: all] Error 2
make[2]: *** [CMakeFiles/BearSource.dir/build.make:134: subprojects/Stamp/BearSource-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:250: CMakeFiles/BearSource.dir/all] Error 2 
make: *** [Makefile:171: all] Error 2

xythrez commented on 2020-09-30 15:45

There has been some major changes in the build process for 3.0.0. Specifically, the way it is set up really doesn't like being wrapped in a PKGBUILD. Right now the program should build and run as expected. I will try to pinpoint the issues at a later date.

Flags that have issues are:

In CXXFLAGS: -fno-plt

In LDFLAGS: -z,now

yut23 commented on 2019-06-21 18:27

I was getting some test failures when trying to build 2.3.13, which I resolved by disabling ccache (add !ccache to the options array in the PKGBUILD).

On my machine, 2.4.0 builds and checks fine after this fix.

codyps commented on 2019-05-31 19:30

Hey folks, I'm trying to get this updated, but I'm seeing test failures with the new version (the PKGBUILD is configured to run the tests) that probably need to be resolved first.

smallmouse commented on 2019-03-18 23:27


I believe python-pycodestyle and python-coverage might be madedepends

codyps commented on 2019-01-30 02:30

@raul_l: using lib64 does not work as lib64 is a symlink (which collides on install of a package trying to use lib64 as a directory)

For this package, it appears that using lib as CMAKE_INSTALL_LIBDIR works around the bug in it's CMakeLists.txt.

@DanielRichtmann: it is an upstream bug (using ${CMAKE_INSTALL_LIBDIR} like that is incorrect), but it's one we can workaround here.

Thank you both for looking into this issue.

raul_l commented on 2019-01-30 02:27

With the latest version I get the ..from LD_PRELOAD cannot be preloaded.. error. It appears to me that CMAKE_INSTALL_LIBDIR should be given as a relative path,


Or I can just leave out that variable (defaults to lib64 in my case), which also works.

DanielRichtmann commented on 2019-01-28 14:40

I just upgraded to 2.3.13 and stumbled across the following which prevents me from running bear without specifying the path to libear explicitly:



From CMakeLists.txt:


Combining these, we get DEFAULT_PRELOAD_FILE equal to /usr//usr/lib/bear/

Is this an issue in the PKGBUILD or should I submit an issue upstream?