On 03/12/2018 08:38 PM, Mark Hatle wrote:
In this case, because the user specifically asked for BOTH 32-bit and 64-bit
development components to be installed onto the target for their application
development.  (This isn't a theoretical problem, but a specific problem from one
of our customers.)

Fair enough, but you should explain to the customer that Unix-type systems are not designed for this. There are hardcoded assumptions everywhere, that for each component there's only one set of header files, one .pc file, and one -config-style helper binary. Desktop distributions mutually exclude multilib -dev packages for this reason.

The under the hood it can rename the 'python3.5m-config' to a nonconflicting
name (based on the base_libdir, since we know that will be unique)... and then
invoke a post-install script that will define an appropriate priority to ensure
that python3.5m-config will match the final 'python3.5m' version.  (Possibly
using update-alternatives to manage this.)

Here's something I don't get. When the user starts actual development, and calls python3.5-config to fetch configuration values, how do we ensure that the 'right' python3.5m-config is called, from the two that are installed? Same question for pkgconfig - how do we make sure it would look in the 'right' library directory of the two that are available?


Openembedded-core mailing list

Reply via email to