Building on PopOS 20.04

[Karl Cunningham]

All,

I'm trying to compile a bareos client on PopOS 20.04. I run cmake from the build directory with the following options:
cmake -Dclient-only=yes -Dconfdir=/etc/bareos ../bareos

But it gives the following error:

CMake Error at core/CMakeLists.txt:640 (message):
build with acl requested, but lib not found

libacl1-dev is installed and /usr/include/sys/acl.h is there.

Doing the same on Ubuntu 18.04 succeeds.
Adding -Dacl=no to the cmake options on PopOS succeeds.

Does anyone have an idea what I'm doing wrong, or what I can do to investigate further?

Thanks,

Karl

[Karl Cunningham]

Well, I guess I need to dig a little deeper before I complain.

I still don't know why this is happening, but I found a workaround.

The  libacl include detection requires both sys/types.h  and  sys/libacl.h, per line 35 of /core/cmake/BareosCheckIncludes.cmake.

On both 18.04 and 20.02, sys/types.h is  found in  /usr/include/x86_64_linux_gnu/  and  sys/libach.h  is found in  /usr/include/.

In 20.04, if I create a symlink:

ln -s /usr/include/x86_64_linux_gnu/sys/types.h  /usr/include/sys/

then cmake runs without error, but it's obviously not solving the underlying problem.

Karl

[Andreas Rogge]

Hi Karl,

I just looked at ubuntu 20.04 and the situation is like you describe:
I have /usr/include/x86_64-linux-gnu/sys/types.h and /usr/include/sys/acl.h

You can look at the compilers default include path as follows:

gcc -xc -E -v - < /dev/null

This will print a lot of information. One section should be something
like "#include <...> search starts here:". There you'll see a list of
directories that are searched for include files.

I don't have easy access to a pop!os (no docker images available), so I
cannot test this quickly. However, CMake does basically something like
the following for the test, so you could minimalize your test-case like
follows:

It creates a source-file e.g. "test.c" with the following content
-- CUT HERE --
#include <sys/types.h>
#include <sys/acl.h>

int main() {
}
-- CUT HERE --

try to compile with "gcc test.c".

If that fails, you have a problem that your compiler does not pick up
/usr/include/x86_64-linux-gnu as an include directory. This would happen
for example if you're compiling on a platform that is not x86_64-linux-gnu.

If it works, probably something in cmake or our cmake configuration is
broken.

Hope that helps!

Best Regards,
Andreas

Am 27.09.20 um 18:36 schrieb Karl Cunningham:

> --
> You received this message because you are subscribed to the Google
> Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bareos-users...@googlegroups.com
> <mailto:bareos-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bareos-users/a39c44c0-8d15-4df7-ab56-16721a32aec8n%40googlegroups.com
> <https://groups.google.com/d/msgid/bareos-users/a39c44c0-8d15-4df7-ab56-16721a32aec8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Andreas Rogge andrea...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz

[Karl Cunningham]

Hi Andreas,

Thanks for the info. The gcc include directories contained the needed ones, and compiling the test code worked fine without symlinking types.h

But the good news is that after doing a git pull on my bareos source tree, cmake runs without error without the symlink. Before updating it, my source tree was at commit 675bde from 10-Sep. A lot seemes to have happened since then, so I can't say exactly what made the difference. And it probably doesn't matter anyway.

Thanks again for your help.

Karl