Bug 200512 - _nss_cache_cycle_prevention_function hack between lib/libc and usr.sbin could probably be done away with using a weak symbol
Summary: _nss_cache_cycle_prevention_function hack between lib/libc and usr.sbin could...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-29 04:12 UTC by Enji Cooper
Modified: 2015-06-03 19:54 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer freebsd_triage 2015-05-29 04:12:25 UTC
Spotted the string 'Undefined symbol "_nss_cache_cycle_prevention_function"' in a corefile that uses nsdispatch.

The lookup's being done in lib/libc/net/nsdispatch.c, however, "_nss_cache_cycle_prevention_function" is only being provided by nscd.

This hack seems horrible and could probably be replaced with a weak symbol...

$ grep -r _nss_cache_cycle_prevention usr.sbin/ lib
usr.sbin/nscd/nscd.c: * The idea of _nss_cache_cycle_prevention_function is that nsdispatch
usr.sbin/nscd/nscd.c:void *_nss_cache_cycle_prevention_function;
lib/libc/net/nsdispatch.c:			"_nss_cache_cycle_prevention_function");
Comment 1 Jilles Tjoelker freebsd_committer freebsd_triage 2015-06-03 19:54:30 UTC
A less magic approach would be to export a function from libc that nscd calls to tell libc not to connect to the caching daemon. nscd should then call this before opening its socket.