uv.hdll exposes a couple of functions that come directly from libuv:
|
DEFINE_PRIM(_LOOP, default_loop, _NO_ARG); |
|
DEFINE_PRIM(_I32, loop_close, _LOOP); |
|
DEFINE_PRIM(_I32, run, _LOOP _I32); |
|
DEFINE_PRIM(_I32, loop_alive, _LOOP); |
|
DEFINE_PRIM(_VOID, stop, _LOOP); |
|
|
|
DEFINE_PRIM(_BYTES, strerror, _I32); |
This means there is no HL_PRIM declaration associated with them.
This is fine on windows, where the library is vendored and the sources are added to the uv.hdll build. This means the symbols for those functions are exported in uv.hdll and there is no issue with using them and linking with uv.hdll.
On non-windows systems, uv.hdll links to the system libuv (usually dynamic). This means the required symbols are not found directly in uv.hdll, but in its dependency (libuv.so). Linking a hlc app using these functions fails therefore with the error.
/usr/bin/ld: hl/functions.o: undefined reference to symbol 'uv_default_loop'
/usr/bin/ld: /usr/lib/libuv.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
To avoid this linking error it is necessary to link the hlc program with -luv which is not ideal as it breaks the hdll abstraction. It also means that special handling is needed to build whenever a hlc program makes use of uv.hdll.
Solution would seem to be to add wrappers for these functions and start using them from now on, while still providing the old ones to not break compatibility.
uv.hdll exposes a couple of functions that come directly from libuv:
hashlink/libs/uv/uv.c
Lines 273 to 279 in fbfedd8
This is fine on windows, where the library is vendored and the sources are added to the uv.hdll build. This means the symbols for those functions are exported in uv.hdll and there is no issue with using them and linking with uv.hdll.
On non-windows systems, uv.hdll links to the system libuv (usually dynamic). This means the required symbols are not found directly in uv.hdll, but in its dependency (libuv.so). Linking a hlc app using these functions fails therefore with the error.
To avoid this linking error it is necessary to link the hlc program with
-luvwhich is not ideal as it breaks the hdll abstraction. It also means that special handling is needed to build whenever a hlc program makes use of uv.hdll.Solution would seem to be to add wrappers for these functions and start using them from now on, while still providing the old ones to not break compatibility.