libyang header installation incompatible with multiarch installation

[eqvinox]

libyang's install includes an autogenerated config.h header, which unfortunately differs between 32-bit and 64-bit:

--- ./work/libyang-2.0.97_build-abi_x86_32.x86/src/config.h     2021-11-21 20:18:56.187900206 +0100
+++ ./work/libyang-2.0.97_build-abi_x86_64.amd64/src/config.h   2021-11-21 20:18:58.627783486 +0100
@@ -21,8 +21,8 @@
 /** plugins */
 #define LYPLG_SUFFIX ".so"
 #define LYPLG_SUFFIX_LEN (sizeof LYPLG_SUFFIX - 1)
-#define LYPLG_TYPE_DIR "/usr/lib/libyang/extensions"
-#define LYPLG_EXT_DIR "/usr/lib/libyang/types"
+#define LYPLG_TYPE_DIR "/usr/lib64/libyang/extensions"
+#define LYPLG_EXT_DIR "/usr/lib64/libyang/types"
 
 /** atomic compiler operations, to be able to use uint32_t */
 #define LY_ATOMIC_INC_BARRIER(var) __sync_fetch_and_add(&(var), 1)

This makes a multi-arch install problematic since that best way to do that is for the headers to not be different.

(Also I think the 2 defines are swapped?)

The best approach here would be to remove these variables and put them into the libyang.pc file instead. pkg-config files can include additional custom variables that can be queried, e.g.:

# cat libyang.pc
prefix=/usr
includedir=${prefix}/include
libdir=${prefix}/lib64
typesdir=${libdir}/libyang/types
extensionsdir=${libdir}/libyang/extensions

Name: libyang
Description: libyang is YANG data modelling language parser and toolkit written (and providing API) in C.
Version: 2.0.97
Requires.private: libpcre2-8
Libs: -L${libdir} -lyang
Libs.private: -lpcre2-8
Cflags: -I${includedir}
# PKG_CONFIG_PATH="`pwd`" pkg-config --variable=extensionsdir libyang
/usr/lib64/libyang/extensions

This solves the problem since 2 libyang.pc files will be installed, one for 32-bit and one for 64-bit.

P.S.: the #if (@CMAKE_C_COMPILER_ID@ == GNU) || (@CMAKE_C_COMPILER_ID@ == Clang) check is wrong too, there is no guarantee that the compiler used to build libyang is the same later used by some application using libyang. The check should be #ifdef __GNUC__ instead (clang defines that too.) And the @LYD_VALUE_SIZE@ replacement might cause issues later too.

[michalvasko]

This makes a multi-arch install problematic since that best way to do that is for the headers to not be different.
The best approach here would be to remove these variables and put them into the libyang.pc file instead.

The defines in question are used in libyang code so putting them in the pkg-config is not a viable solution. The only possibility to unify these paths is to change it to an arch-independent path and I do not think your use-case is common enough to justify such a change. What you should do, I suppose, is to install libyang with different prefix for different architecture to avoid any problems.

(Also I think the 2 defines are swapped?)

Yep, fixed.

the #if (@CMAKE_C_COMPILER_ID@ == GNU) || (@CMAKE_C_COMPILER_ID@ == Clang) check is wrong too...

That is true, fixed.

And the @LYD_VALUE_SIZE@ replacement might cause issues later too.

Similar problem as the first one, if you have several installations of libyang with this define different, you need to make sure you are not mixing their headers and libraries. This value is, again, used in the code so I am not sure what solution would you propose, this is the responsibility of the user.

EDIT: Okay, the paths are used only in the code so they could be removed from this public header and really moved to the .pc file so they are still available for users. However, LYD_VALUE_SIZE is used in a public header so there is nothing we can do about that one. Would the proposed change be fine and solve your issue?