epics-modules / alive

APS BCDA synApps module: alive
Other
1 stars 3 forks source link

alive/tests does not build on win32-x86 #4

Closed MarkRivers closed 3 years ago

MarkRivers commented 6 years ago

alive/tests gives unresolved globals for network functions like htons, recvfrom, etc.

The problem is that it is not linking with ws2_32.lib. It does build OK on win32-x86-static, because there $(EPICS_IOC_BASE_LIBS) does include ws2_32.lib.

I changed the Makefile in 53606ca5f57575553ff62d28fad09de858f55d5d as follows

corvette:~/devel/alive/tests>git diff HEAD^ Makefile
diff --git a/tests/Makefile b/tests/Makefile
index 7609a55..c1f2449 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -25,6 +25,7 @@ TESTSPEC_vxWorks = aliveTestHarness.munch; runTests

 PROD_LIBS += alive
 PROD_LIBS += $(EPICS_BASE_IOC_LIBS)
+PROD_SYS_LIBS_WIN32 += ws2_32

 TESTSCRIPTS_HOST += $(TESTS:%=%.t)

However, I am not sure this is the best way to do it.

@anjohnson why is it necessary to explicitly link the test application with ws2_32.lib when building it dynamically on Windows but not when building it statically?

anjohnson commented 3 years ago

We don't explicitly link that library into all programs on Windows because most of them won't need it. In this case the test code is using routines from that library, so its Makefile must add it to the list of libraries to be linked.

Static builds happen to work without including it because there is code in Base that needs that library, and for a static build of an executable the link line must specify every library that is needed by all the code being linked, so the build system automatically adds the libraries that libCom.a and libCa.a depend on too. For a dynamic build of an executable the link line doesn't have to list upstream libraries that have already been linked into the shared libraries that the executable is linking to, so the build only includes the libraries that the Makefile asks for.