Andrew Deason <adea...@sinenomine.net> writes: > No, krb5-config --deps doesn't exist in any release of heimdal I'm aware > of (1.5.3 didn't seem to have it). And Måns is using heimdal 1.2.1, > which certainly does not have --deps (discussed briefly offline).
windlord:~> krb5-config.heimdal --deps --libs -L/usr/lib/i386-linux-gnu/heimdal -lkrb5 -lhx509 -lcom_err -lhcrypto -lasn1 -lwind -lheimbase -lroken -lcrypt -pthread -lpthread -ldl -lresolv -pthread -lpthread windlord:~> krb5-config.heimdal --libs -L/usr/lib/i386-linux-gnu/heimdal -lkrb5 windlord:~> krb5-config.heimdal --version heimdal 1.5.99 So it does exist in Heimdal, but it's apparently more recent than I thought. I know Derrick ran into this, but that was probably with Mac OS X. Maybe Macs acquired --deps sooner than the widely used UNIX releases? > Well that's a little strange. Running this manually and removing > arguments reveals that Solaris Studio doesn't like -pthreads (it > interprets it as the options -p, -h, etc, and obviously -h is not > correct). And krb5-config does indeed say -pthreads for krb5-config > --libs. Aha. > So, what is the avenue for fixing this? Should heimdal not be giving us > -pthreads for --libs? (and does it avoid that, in future versions?) No, it's required to get proper threading behavior, I believe. > Does newer rra-c-util strip it out? No, nor will it; the whole point of using krb5-config is that we trust krb5-config, and I don't know the implications of not using -pthreads nor want to take responsibility for second-guessing the Kerberos configuration. > Should we strip it out? Maybe; it might make sense to strip it after the fact (outside of the imported macros) when you know you're using Solaris cc. Do you care about threading behavior for any of the places you link with Kerberos libraries? Really, the actual answer is that people should use consistent compiler environments or they're going to be in for a world of hurt. In other words, build OpenAFS with the same compiler that you built Heimdal with and then it would work. Easier said than done in 1.6, of course; that's OpenAFS's bug, not the user's, because we force a compiler that people are not using for other things on their system. That in turn is because we force the compiler for all of OpenAFS just because of the kernel modules. > Should the manual libkrb5 probing work after the 'krb5-config --libs' > sanity check fails? Yes. In the absence of --enable-reduced-depends, the point of the manual probing is to try to get all of the libraries that would be required for static linkage. There are a bunch of new ones that were introduced, so there should be more cases like: AC_SEARCH_LIBS([roken_concat], [roken]) for the other Heimdal libraries. Also, the Heimdal libraries need to be stuck into something other than rra_krb5_extra; it looks like right now we're linking with libroken even if we end up discovering MIT libraries, which is wrong. I can see how to fix this, I think, but what would help is if someone would research the additional libraries I should be probing for and what symbols (like roken_concat) are good ones to look for. Although even if it does manage to find the libraries required to get things to link, the threaded behavior would still be wrong. I'm not sure if we care for any of the code that's in OpenAFS. The MIT manual probing does check for -lpthreads and -lpthread because MIT needed that in some cases, but I don't know if just linking and not using -pthread is sufficient on all platforms. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info