{"action":"opened","issue":{"url":"https://api.github.com/repos/flux-framework/flux-core/issues/179","labels_url":"https://api.github.com/repos/flux-framework/flux-core/issues/179/labels{/name}","comments_url":"https://api.github.com/repos/flux-framework/flux-core/issues/179/comments","events_url":"https://api.github.com/repos/flux-framework/flux-core/issues/179/events","html_url":"https://github.com/flux-framework/flux-core/issues/179","id":73677187,"number":179,"title":"API: resolve circular linking dependency in flux-core build system","user":{"login":"garlick","id":169947,"avatar_url":"https://avatars.githubusercontent.com/u/169947?v=3","gravatar_id":"","url":"https://api.github.com/users/garlick","html_url":"https://github.com/garlick","followers_url":"https://api.github.com/users/garlick/followers","following_url":"https://api.github.com/users/garlick/following{/other_user}","gists_url":"https://api.github.com/users/garlick/gists{/gist_id}","starred_url":"https://api.github.com/users/garlick/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/garlick/subscriptions","organizations_url":"https://api.github.com/users/garlick/orgs","repos_url":"https://api.github.com/users/garlick/repos","events_url":"https://api.github.com/users/garlick/events{/privacy}","received_events_url":"https://api.github.com/users/garlick/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-05-06T16:55:34Z","updated_at":"2015-05-06T16:55:34Z","closed_at":null,"body":"Because modules need to use the functions provided by `libflux-core.so` but themselves provide interfaces that are included in `libflux-core.so`, we have been statically linking modules and utilities so that we can get these things built incrementally.\r\n\r\nThis could be avoided if we move module interfaces (like those provided by `libkvs.a`, `libbarrrier.a`, etc) to separate shared objects that a user explicitly links against, or provide a demand loadable handle for module interfaces as described in issue #176"}}