(Not for 1.4, but maybe for consideration post 1.4...) I've played around a little bit with producing warnings for code using functions we've marked as deprecated. I see two possible approaches, both of which are specific to the GNU tools at least at the moment (though I think that covers a pretty good portion of our developer-user base). Each has benefits and drawbacks. * GCC "deprecated" attribute in declarations This involves annotations in krb5.h, and produces warnings when a source file is compiled that uses a deprecated symbol. (Actually, I haven't looked at whether it applies to non-function symbols, but I don't think we have many of those to worry about.) The result looks like: foo.c:3: warning: `old_fn' is deprecated (declared at foo.c:2) In our source tree, we have quite a few references to krb5_c_random_seed, but also krb5_auth_con_initiivector and the get_in_tkt functions. You can't offhand tell if the referencing code itself is marked as deprecated. We should probably fix most of them anyways; if we can't implement our code without use of deprecated functions, how can we expect anyone else to? * GNU linker warnings On ELF systems, the GNU linker will emit any message stored in an ELF section .gnu.warning. if is referenced. With gcc, an asm statement in the source file defining the deprecated function is the best way to produce that section. (Similar hacks can be done for a.out/stabs systems, if we care.) The asm ickiness can be hidden in a small macro in k5-platform.h quite easily, so the library source files just have macro invocations. Minor annoyance: To avoid empty top-level declarations in the case where this functionality isn't supported, the macro invocation should *not* be followed by a semicolon. This makes the Emacs indentation code a bit unhappy. With this approach, we get control over the warning message text. This is good in that we can cause the text to recommend a replacement function, but less than ideal from an i18n perspective, where gcc emits locale-specific messages and then we dump out a string in English. Object files and libraries built with other tools but linked with the GNU linker against gcc-compiled krb5 libraries would still have checks done. Well, for object files linked in; a deprecated, unused object file in an archive library that references deprecated krb5 functions wouldn't produce a warning. One possibly serious drawback: An object file with two functions, one used by the application and the other, unused one referencing a deprecated symbol, can produce a warning during static linking. In a static build in our tree, warnings about old_api_glue.c references to krb5_c_random_seed are common. If we still care that much about static linking, and want link-time warnings, we could split out any such references that we can't eliminate into separate source files. The result of my sample implementation looks like: kprop.o(.text+0x44e): In function `get_tickets': ../../src/slave/kprop.c:301: warning: krb5_get_in_tkt_with_keytab is deprecated; use krb5_get_init_creds_keytab I don't know if uses of dlopen/dlsym will emit the warnings. * Facilities in other (non-GNU) toolchains? I don't know about any such facilities in other compiler toolchains we use; if anyone does, I'd be interested to hear about them, to see whether we might be able to make use of them as well. In test builds of the current tree on Linux with the attached patch, the attribute caused 18 compile-time warnings; the linker emitted 10 warnings in a shared-library build, and 80 in a static-library build, with old_api_glue.c causing most of the extra warnings in the static case. Ken