On Thu, Nov 01, 2018 at 02:31:37AM +0000 I heard the voice of
Yumekui Neru, and lo! it spake thus:
>
> The build fails when built using an ebuild with the portage package
> manager, though is successful if built "manually" with make (and in
> portage after changing the aforementioned line).
Iiiiiinteresting. So that the failure is in fact happening when
trying to link ctwm, not the libctwmlib.a. My guess is that it's
because the ebuild has
-Wl,--as-needed
as a linker flag, and doing it manually doesn't; I see some refs to
ebuild forcing that in LDFLAGS. And --as-needed is neat, but also
really stupid, because it ignores libs it doesn't need, where "doesn't
need" is defined as "no object file I've seen yet in the command line
needs those symbols". And since libctwmlib.a comes after the -l flags
for the shared libs, it decided it didn't need any of them before it
even got there, and then found a bunch of symbols it couldn't resolve.
So, the _real_ solution is to fix ld(1) to be less stupid...
A more likely and practical solution would be to try swapping around
the order of the libs. e.g.:
=== modified file 'CMakeLists.txt'
--- CMakeLists.txt 2018-10-22 00:02:28 +0000
+++ CMakeLists.txt 2018-11-01 02:51:09 +0000
@@ -126,8 +126,8 @@
# with access to all our internal funcs.
add_library(ctwmlib STATIC ${CTWMSRC})
add_executable(ctwm "ctwm_wrap.c")
+target_link_libraries(ctwm ctwmlib)
target_link_libraries(ctwm ${CTWMLIBS})
-target_link_libraries(ctwm ctwmlib)
# This doesn't really serve much purpose at the moment, so it's not even
# documented, but the code exists. So make it buildable.
so the .a is before the -l's, and see if that whips it into shape.
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
