/var/tmp/portage/sys-apps/openrc-0.7.0/work/openrc-0.7.0/src/test * Checking exported symbols in libeinfo.so (data) ... [ ok ] * Checking exported symbols in libeinfo.so (functions) ... [ ok ] * Checking exported symbols in librc.so (data) ... [ ok ] * Checking exported symbols in librc.so (functions) ... [ ok ] * Checking hidden functions in librc.so ... * Missing hidden defs: rc_conf_value [ !! ] * Running unit tests * is_older_than ... [ ok ] make[2]: *** [check] Error 1 make[2]: Leaving directory `/var/tmp/portage/sys-apps/openrc-0.7.0/work/openrc-0.7.0/src/test' make[1]: *** [check] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-apps/openrc-0.7.0/work/openrc-0.7.0/src' make: *** [check] Error 2 emake failed
Created attachment 259730 [details] log
the new rc_sys code is a bit broken. commit 09f990a7c835d75f67cfe696 (Implement explicit selection of subsystem types.) has the librc.so library use a function which is only implement in the `rc` binary. the build works only because openrc only links rc itself against librc.so thus satisfying the missing symbol. so either librc needs to stop using rc_conf_value, or that func needs to be moved to librc. the latter is probably ok. that patch is also broken in that it renames publicly exported symbols. it probably isnt a big deal though since realistically, `rc` is the only consumer. but it does sort of defeat the whole point ...
(In reply to comment #2) > the new rc_sys code is a bit broken. commit 09f990a7c835d75f67cfe696 > (Implement explicit selection of subsystem types.) has the librc.so library use > a function which is only implement in the `rc` binary. the build works only > because openrc only links rc itself against librc.so thus satisfying the > missing symbol. > so either librc needs to stop using rc_conf_value, or that func needs to be > moved to librc. the latter is probably ok. Also, we need to look into what is going on with rc_deptree_load_file since it is getting the same failure. > that patch is also broken in that it renames publicly exported symbols. it > probably isnt a big deal though since realistically, `rc` is the only consumer. > but it does sort of defeat the whole point ... I agree that we shouldn't be renaming publically exported symbols without a good reason. Is there any chance of renaming those exported symbols back to what they were before this patch?
(In reply to comment #3) > > that patch is also broken in that it renames publicly exported symbols. it > > probably isnt a big deal though since realistically, `rc` is the only consumer. > > but it does sort of defeat the whole point ... > I agree that we shouldn't be renaming publically exported symbols without a > good reason. Is there any chance of renaming those exported symbols back to > what they were before this patch? Looking at this further, I think this involves the symbols rc_sys, rc_sys_v1 and rc_sys_v2. So, I think what happened is we just got two new exported symbols. Mike, is that correct? If so, I would say that we just need to rework the code so that rc_sys_v1 and rc_sys_v2 are not exported, which shouldn't be that difficult. What other public symbols were affected?
I've fixed the code to pass the tests now. (In reply to comment #4) > Looking at this further, I think this involves the symbols rc_sys, rc_sys_v1 > and rc_sys_v2. So, I think what happened is we just got two new exported > symbols. Yes, what was the "rc_sys" function is now "rc_sys_v1". The new "rc_sys" function calls either rc_sys_v2 or rc_sys_v1 depending on the existence of the rc_sys config value in rc.conf. The rc_sys function itself exists to preserve ABI compat > Mike, is that correct? If so, I would say that we just need to rework the code > so that rc_sys_v1 and rc_sys_v2 are not exported, which shouldn't be that > difficult. They are exported for use in the 'rc' binary where 'rc -S' exposes the subsystem-detection results. > What other public symbols were affected? rc_deptree_load_file was a similar refactor of rc_deptree_load, converting the old function to take a new argument, and providing a compatibility function with the old function signature for ABI compatibility.
*** Bug 353006 has been marked as a duplicate of this bug. ***
