Bug#919705: move libapparmor.so to /lib/<triplet>

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#919705: move libapparmor.so to /lib/<triplet>

Helmut Grohne
Package: libapparmor-dev
Version: 2.13.2-3
Tags: patch
User: [hidden email]
Usertags: rebootstrap
Control: affects -1 + src:libvirt

I tried cross building libvirt. It still has a few issues, but one of
the issues is that it fails to find libapparmor (not immediately
visible). In the end, I was able to reduce the libvirt's check to the
following command:

echo 'main(){return aa_change_profile();}' | $CC -x c - -o /dev/null -lapparmor

If $CC is a native compiler, it just works. If $CC is a cross compiler
(e.g. for arm64), you get an error:

/usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /lib/aarch64-linux-gnu/libapparmor.a(kernel.o): in function `aa_query_label@@APPARMOR_2.9':
(.text+0x1248): undefined reference to `pthread_once'

What you can see here is that for some reason gcc is preferring the
static library over the dynamic one. So I started looking and compared
$CC -print-search-dirs. Indeed, for native toolchains /usr/lib/<triplet>
comes before /lib/<triplet>. For Debian's cross toolchains, this order
is reversed for some reason. I'm not sure whether that's a bug in the
cross toolchains. However, it causes gcc to prefer the static library
over the dynamic one.

I've concluded that regardless of whether this is a bug in gcc, it is a
bug in libapparmor-dev. I think that putting static and dynamic
libraries in different directories is a recipe for breakage. You really
should put them in the same directory. That can be either /lib/<triplet>
or /usr/lib/<triplet>. Implementing the former is easier so that's what
my patch does. Would you be so kind and fix this on the apparmor side?

Helmut

apparmor_2.13.2-3.1.debdiff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919705: [pkg-apparmor] Bug#919705: move libapparmor.so to /lib/<triplet>

intrigeri-4
Hi Helmut,

Helmut Grohne:
> I've concluded that regardless of whether this is a bug in gcc, it is a
> bug in libapparmor-dev. I think that putting static and dynamic
> libraries in different directories is a recipe for breakage. You really
> should put them in the same directory. That can be either /lib/<triplet>
> or /usr/lib/<triplet>. Implementing the former is easier so that's what
> my patch does. Would you be so kind and fix this on the apparmor side?

Thanks for looking into this problem in depth and for the patch! :)

I'm by far no expert in this area but your analysis and conclusions
make sense to me; they also match what I see other packages do.
I've applied your patch locally and will upload in the next couple
days unless testing displays issues.

Cheers,
--
intrigeri

Reply | Threaded
Open this post in threaded view
|

Bug#919705: [pkg-apparmor] Bug#919705: move libapparmor.so to /lib/<triplet>

intrigeri-4
In reply to this post by Helmut Grohne
Hi,

intrigeri:
> Helmut Grohne:
>> I've concluded that regardless of whether this is a bug in gcc, it is a
>> bug in libapparmor-dev. I think that putting static and dynamic
>> libraries in different directories is a recipe for breakage. You really
>> should put them in the same directory. That can be either /lib/<triplet>
>> or /usr/lib/<triplet>. Implementing the former is easier so that's what
>> my patch does. Would you be so kind and fix this on the apparmor side?

I've just remembered this morning that I had blindly trusted the patch
to do what it claims, without actually testing it before uploading.
And unfortunately, it does not: libapparmor-dev 2.13-4 still installs
the unversioned symlink in /usr/lib/<triplet>/libapparmor.so.

I'll try to fix this right away. I suspect it'll raise the
dev-pkg-without-shlib-symlink Lintian warning but then this might be
a bug in Lintian (#843932).

Cheers,
--
intrigeri