[1/1] libcap: depend on host-attr for the host

Dear Ben Boeckel,

On Sat, 24 Oct 2015 17:39:14 -0400, Ben Boeckel wrote:
> When a host-libcap is built, it is built without libattr support.
> However, libcap does not define some symbols based on this flag. This
> becomes a problem when a build-host tool is run (e.g., ls) which uses
> these symbols gets the host-libcap library via LD_LIBRARY_PATH.

Ok, so let me try to understand this a bit better. You say that if you
have host-libcap built and installed in $(HOST_DIR), then when you
build another package, if the build process of that package uses your
system 'ls' (i.e /bin/ls), then this ls doesn't work properly because
it uses $(HOST_DIR)/usr/lib/libacl.so instead of /usr/lib/libacl.so.

Is that correct ?

If that is correct, then I think your proposed change is not the right
solution, because it is just a workaround for the specific situation,
on your distribution, where ls gets linked against an acl that has attr
support. A similar problem can appear with other binaries/libraries,
and we don't want to clutter our host package dependencies to solve
such problems IMO.

Instead, I believe we should look at removing $(HOST_DIR)/usr/lib from
LD_LIBRARY_PATH, i.e do something like:


We do build all host binaries in $(HOST_DIR) with a rpath that points
to $(HOST_DIR)/usr/lib, so this LD_LIBRARY_PATH should not be
necessary. And this LD_LIBRARY_PATH is indeed wrong as it means that
any system binary will first use the Buildroot-built host libraries
rather than the system ones, as you experienced. These LD_LIBRARY_PATH
were introduced back in February 2010, at a time when we were not
building host binaries with a rpath. So I believe they should by now be
unnecessary, and as you found out, potentially harmful.

Thomas

On Mon, Oct 26, 2015 at 09:58:27 +0100, Thomas Petazzoni wrote:
> On Sat, 24 Oct 2015 17:39:14 -0400, Ben Boeckel wrote:
> > When a host-libcap is built, it is built without libattr support.
> > However, libcap does not define some symbols based on this flag. This
> > becomes a problem when a build-host tool is run (e.g., ls) which uses
> > these symbols gets the host-libcap library via LD_LIBRARY_PATH.
> 
> Ok, so let me try to understand this a bit better. You say that if you
> have host-libcap built and installed in $(HOST_DIR), then when you
> build another package, if the build process of that package uses your
> system 'ls' (i.e /bin/ls), then this ls doesn't work properly because
> it uses $(HOST_DIR)/usr/lib/libacl.so instead of /usr/lib/libacl.so.
> 
> Is that correct ?

Yes.

> If that is correct, then I think your proposed change is not the right
> solution, because it is just a workaround for the specific situation,
> on your distribution, where ls gets linked against an acl that has attr
> support. A similar problem can appear with other binaries/libraries,
> and we don't want to clutter our host package dependencies to solve
> such problems IMO.
> 
> Instead, I believe we should look at removing $(HOST_DIR)/usr/lib from
> LD_LIBRARY_PATH, i.e do something like:
<snip>

This sounds like a much better solution.

Thanks,

--Ben

Ben,

On Mon, 26 Oct 2015 10:27:25 -0400, Ben Boeckel wrote:

> > If that is correct, then I think your proposed change is not the right
> > solution, because it is just a workaround for the specific situation,
> > on your distribution, where ls gets linked against an acl that has attr
> > support. A similar problem can appear with other binaries/libraries,
> > and we don't want to clutter our host package dependencies to solve
> > such problems IMO.
> > 
> > Instead, I believe we should look at removing $(HOST_DIR)/usr/lib from
> > LD_LIBRARY_PATH, i.e do something like:
> <snip>
> 
> This sounds like a much better solution.

Does this mean you will send a patch for it, after doing some testing ?

Thanks!

Thomas

On Tue, Oct 27, 2015 at 07:29:54 +0100, Thomas Petazzoni wrote:
> Does this mean you will send a patch for it, after doing some testing ?

Patch sent. Tested locally by building util-linux.

Thanks,

--Ben