Hi all, It seems this saga never ends.
With the current state of affairs in sid, MIT krb5's krb5-config and/or pkg-config are always emitting -isystem stanzas to find the krb5 headers. My understanding (which is not completely field tested, but I'm fairly confident) is that if there are MIT headers in /usr/include/mit-krb5 and Heimdal headers in /usr/include/heimdal, then I can have an application which uses MIT's libkrb5 and a helper library (such as libroken) from Heimdal, so long as -I/usr/include/mit-krb5 comes before -I/usr/include/heimdal on the compiler command line. When -isystem /usr/include/mit-krb5 is used, that directory is treated as a location of system headers, which means it is automatically moved to the end of the include search path, so such an application would always get the Heimdal krb5.h (and fail to compile if it's doing anything nontrivial). The immediate case where I'm encountering this issue is a development version of openafs (see #761933), which will want to use libroken and libhcrypto. However, I suspect there are other Heimdal libraries that could be used without conflicts in an MIT-krb5-using application. I see two immediate solutions to my particular problem: (1) switch openafs to using Heimdal, which I am reluctant to do because of the changes it would force on users, (2) have separate libroken-dev and libhcrypto-dev packages so that I can get those headers without pulling in Heimdal's krb5.h which causes problems, which is more work for Jelmer (even if someone else contributes the patches, realistically), and (3) use the --with-krb5-lib and --with-krb5-include from rra-c-util (thanks, Russ!) and patch openafs such that the includes are processed in the proper order (they currently are not; I guess realistically I would have to do this patching even if krb5-config was not emitting -isystem). I know that this sort of mixed MIT/Heimdal application is pretty uncommon (largely because of the difficulty involved in getting it to work properly), but maybe we should do something better than the current state of affairs. Any other thoughts, whether for the openafs case in particular or the more general case? -Ben -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
