| Summary: | multilib-build.eclass: multilib_check_headers refuses to merge when headers are only present for native ABI | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jocelyn Mayer <l_indien> |
| Component: | Eclasses | Assignee: | Michał Górny <mgorny> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | enhancement | CC: | l_indien, mgorny |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
dev-libs/imath log file when attempting to merge it as a multilib package.
dev-libs/imath ebuild patch used for multilib compilation dev-libs/imath x86_32 ABI support patch media-libs/openexr ebuild patch used for multilib compilation |
||
Isn't this what the wrapped array is for? Created attachment 848737 [details, diff]
dev-libs/imath ebuild patch used for multilib compilation
Created attachment 848739 [details, diff]
dev-libs/imath x86_32 ABI support patch
Created attachment 848741 [details, diff]
media-libs/openexr ebuild patch used for multilib compilation
This is working as intended. If headers are installed only for the native ABI, then packages built for other ABIs cannot use these headers. Therefore, they need to be wrapped to prevent them from being used by builds on non-native ABIs. This might be the case for most package. For the imath package, the native ABI headers contain checks like: if !defined(__x86_64__) // if defined(__x86_64__) so they are safe to be use for 32 ABI even if not installed explicitly for the 32 bits ABI. Maybe a specific ebuild MULTILIB_xxx variable may be added to allow the case only for packages that proove to be safely used with the non native ABI(s) ? (In reply to Jocelyn Mayer from comment #6) > This might be the case for most package. > For the imath package, the native ABI headers contain checks like: > if !defined(__x86_64__) // if defined(__x86_64__) > so they are safe to be use for 32 ABI even if not installed explicitly for > the 32 bits ABI. > Maybe a specific ebuild MULTILIB_xxx variable may be added to allow the case > only for packages that proove to be safely used with the non native ABI(s) ? How would that be useful if the 32-bit library is not installed? in the example I used there, the 32 bits library is installed, which allows one to build a multilib openexr package, which will allow use of multilib opencv with openexr support allowed for 32 bits apps. There sure are more examples to find... maybe my explanations weren't clear, for this specific case: in case one tries to build it with multilib, all specified ABI libraries are properly built and installed. The only drawback is that only the main ABI installs headers. No headers for alternate ABIs being installed and the main ABI headers being safe for use for all ABIs, at least on x86_64 arch, it seems safe to merge the package. My suggestion was not to merge when there only are headers additions, but when there only are headers installed for the main ABI, which seems to me to be quite a good practice from the developers in order to avoid file collisions, it seems this point was actually not clear at all ! |
Created attachment 848735 [details] dev-libs/imath log file when attempting to merge it as a multilib package. When trying to merge some multilib packages, there may be packages that would not install headers but for the native ABI. There would be no difference between native and multilib ABI headers. I then suggest that, in the case the difference between installed headers in only additional headers for the native ABI, multilib_check_headers would not emit any error. An example could be dev-libs/imath: it could be merged as a multilib package when adding this behavior as it just does not install any headers but for the native ABI. This specific case would be of use in order to be able to build a multilib version of media-libs/openexr, as an example.