#1671 library layering violation (libnetsnmphelpers)
Trying to build version 5.4pre1 (and 5.3.1 and 5.3.0.1) on Mac OS X -
although I believe this to be a generic problem - fails because the
various libraries violate the layering defined by the source hierarchy.
When I disable accepting undefined symbols in an attempt to identify
dependent libraries, libnetsmp builds fine but libnetsnmphelpers fails.
Adding the equivalent of "../../snmplib/.libs/libnetsnmp.la" resolves
many of the symbols. The remainder, however, are apparently built by
libnetsnmpagent (or libnetsnmpmibs) in the parent directory. (Would
libnetsnmphelpers work better as a static lib linked into both the
parent dylibs?)
(I am trying to resolve the layering issues since Mac OS X uses two-
level namespaces: the library can link against its dependent libraries
and frameworks without forcing something linking against it to
manage all the dependencies. This is necessary to properly link all the
net-snmp binaries; by allowing undefined symbols, the link succeeds
but launch fails.)
For reference, here are the lists of undefined symbols in
libnetsnmphelpers with and without adding -lnetsnmp:
-- With -lnetsnmp --
ld: Undefined symbols:
_netsnmp_call_next_handler
_netsnmp_check_requests_error
_netsnmp_create_handler
_netsnmp_handler_free
_netsnmp_register_handler_by_name
_netsnmp_agent_add_list_data
_netsnmp_agent_get_list_data
_netsnmp_inject_handler
_netsnmp_register_handler
_netsnmp_request_set_error_all
_netsnmp_call_handler
_netsnmp_create_handler_registration
_netsnmp_request_add_list_data
_netsnmp_request_get_list_data
_netsnmp_set_request_error
_netsnmp_marker_uptime
_netsnmp_handler_registration_free
_netsnmp_register_handler_nocallback
_netsnmp_free_request_data_sets
_netsnmp_find_handler_data_by_name
_netsnmp_free_agent_data_sets
/usr/bin/libtool: internal link edit command failed
-- Without -lnetsnmp --
ld: Undefined symbols:
_debugmsg
_debugmsgtoken
_netsnmp_call_next_handler
_netsnmp_check_requests_error
_netsnmp_create_handler
_netsnmp_handler_free
_netsnmp_register_handler_by_name
_se_find_label_in_slist
_snmp_get_do_debugging
_snmp_log
_atime_newMarker
_atime_ready
_atime_setMarker
_debugmsg_oid
_netsnmp_agent_add_list_data
_netsnmp_agent_get_list_data
_netsnmp_create_data_list
_netsnmp_ds_get_boolean
_netsnmp_ds_get_int
_netsnmp_inject_handler
_netsnmp_oid_equals
_netsnmp_register_handler
_netsnmp_request_set_error_all
_snmp_alarm_register
_snmp_alarm_unregister
_snmp_duplicate_objid
_netsnmp_call_handler
_debug_is_token_registered
_snmp_oid_compare
_snmp_set_var_objid
_memdup
_netsnmp_create_handler_registration
_netsnmp_request_add_list_data
_netsnmp_request_get_list_data
_netsnmp_set_request_error
_snmp_set_var_typed_value
_netsnmp_marker_uptime
_debugmsg_var
_netsnmp_handler_registration_free
_netsnmp_register_handler_nocallback
_snmp_call_callbacks
_netsnmp_oid_stash_free
_netsnmp_oid_stash_get_data
_netsnmp_oid_stash_getnext_node
_snmp_free_var
_netsnmp_free_all_list_data
_netsnmp_oid_stash_add_data
_snmp_clone_varbind
_CONTAINER_FREE
_CONTAINER_INSERT
_CONTAINER_REMOVE
_netsnmp_compare_netsnmp_index
_netsnmp_container_find
_netsnmp_ncompare_netsnmp_index
_build_oid_noalloc
_netsnmp_free_request_data_sets
_netsnmp_get_list_node
_snmp_free_varbind
_build_oid
_config_pwarn
_copy_nword
_get_tree
_get_tree_head
_mib_to_asn_type
_netsnmp_add_list_data
_netsnmp_get_list_data
_netsnmp_strdup_and_null
_read_config_read_memory
_register_app_config_handler
_snmp_parse_oid
_snmp_varlist_add_variable
_snprint_objid
_snmp_oidtree_compare
_count_varbinds
_netsnmp_find_handler_data_by_name
_netsnmp_free_agent_data_sets
_parse_oid_indexes
_parse_one_oid_index
_snmp_clone_mem
_snmp_reset_var_buffers
_sprint_realloc_by_type
/usr/bin/libtool: internal link edit command failed
make[3]: *** [libnetsnmphelpers.la] Error 1
Logged In: YES
user_id=88893
What happens if you add the equivalent of linking with
libnetsnmpagent? Does libnetsnmphelpers build then?
As I understand it, there should be a strict dependency chain:
libnetsnmpmibs depends on libnetsnmphelpers
both of these depend on libnetsnmpagent
all 3 of these depend on libnetsnmp
I'm not immediately sure how this maps into the OS X
namespace mechanism.
Logged In: YES
user_id=1551723
I can not add the quivalent of linking with libnetsnmpagent because it hasn't
been built yet. The make file builds libnetsnmphelpers first because
libnetsnmpagent apparently depends on libnetsnmphelpers, but
libnetsnmphelpers clearly uses symbols built by libnetsnmpagent, hence the
layering violation.
Since you claim the dependency chain is different from the way the make file
defines it, I will try to change the build order and see if it has any effect.
Logged In: YES
user_id=88893
OK - on closer examination, the dependencies aren't as clean
as I'd assumed. The helper library relies quite heavily on
the agent library (some two dozen functions), but there are
also a handful of helper library functions that are used by
the agent library code:
bulk_to_next_handler (used in snmp_agent.c)
register_null {
register_null_context { (agent_registry.c)
register_old_api {
init_helpers (snmp_vars.c)
It should be relatively simple to change the order of
compilation, to build the agent library before the helpers.
But I'm not sure how to avoid these particular circular
dependencies. (Or even if it's possible at all)
Ummmm...
Logged In: YES
user_id=1551723
...hence the layering violation. ;-)
Logged In: YES
user_id=76242
solution: just build static ;-)
Logged In: YES
user_id=76242
Chris,
I've just removed the forced library-build-time linking of
libagent to libhelpers in agent/Makefile.in. I think this
actually at least lets it build because this is what we
always did in the past and no one complained until 5.4
where the change was introduced. Can you check?