Cannot build on macOS 10.15 (Catalina)

Eddy Hahn eddyhahn at hotmail.com
Tue Apr 28 17:36:39 UTC 2020


Hi,

I got the latest source and build tools. 

1) autorecon -If. WORKED!

2) configure WORKED!

	LIBUV_LIBS="-L$/dependencies/libuv/lib" LIBUV_CFLAGS="-I$/dependencies/libuv/include" CPPFLAGS=“-I$/dependencies/libuv/include" LDFLAGS='-flat_namespace -force_flat_namespace' ./configure --prefix=“/opt/target" --with-openssl="/dependencies/openssl" --disable-pthread-rwlock --with-libxml2=no --enable-full-report


There are two issues

1) make - FAILS

	it fails because the declaration of the uv_handle_get_data and uv_handle_set_data does not match the declaration between uv-compat.h and  uv.h

In file included from netmgr/netmgr.c:33:
In file included from netmgr/netmgr-int.h:34:
netmgr/uv-compat.h:24:1: error: static declaration of 'uv_handle_get_data' follows non-static declaration
uv_handle_get_data(const uv_handle_t *handle) {
^
/opt/serverplus/dependencies/libuv/include/uv.h:448:17: note: previous declaration is here
UV_EXTERN void* uv_handle_get_data(const uv_handle_t* handle);
                ^
In file included from netmgr/netmgr.c:33:
In file included from netmgr/netmgr-int.h:34:
netmgr/uv-compat.h:31:1: error: static declaration of 'uv_handle_set_data' follows non-static declaration
uv_handle_set_data(uv_handle_t *handle, void *data) {
^
/opt/serverplus/dependencies/libuv/include/uv.h:450:16: note: previous declaration is here
UV_EXTERN void uv_handle_set_data(uv_handle_t* handle, void* data);
               ^
2 errors generated.
make[4]: *** [netmgr/libisc_la-netmgr.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


If I move the declaration from uv-compat.h to uv-compat.c then it compile and we removed the inlining.

Comment out these:

#ifndef HAVE_UV_HANDLE_GET_DATA
static inline void *
uv_handle_get_data(const uv_handle_t *handle) {
        return (handle->data);
}
#endif /* ifndef HAVE_UV_HANDLE_GET_DATA */

#ifndef HAVE_UV_HANDLE_SET_DATA
static inline void
uv_handle_set_data(uv_handle_t *handle, void *data) {
        handle->data = data;
}
#endif /* ifndef HAVE_UV_HANDLE_SET_DATA */

Add to uv-compat.c

#ifndef HAVE_UV_HANDLE_GET_DATA
UV_EXTERN void *
uv_handle_get_data(const uv_handle_t *handle) {
        return (handle->data);
}
#endif /* ifndef HAVE_UV_HANDLE_GET_DATA */

#ifndef HAVE_UV_HANDLE_SET_DATA
UV_EXTERN void
uv_handle_set_data(uv_handle_t *handle, void *data) {
        handle->data = data;
}
#endif /* ifndef HAVE_UV_HANDLE_SET_DATA */



2) deployed executable fails to load lib (deployed using make install)

Once the binaries are built and try to start the named up receive the following error

./named -c /named.conf -f -d4


dyld: lazy symbol binding failed: Symbol not found: _uv_loop_init
  Referenced from: <full path herer>lib/libisc.1701.dylib
  Expected in: flat namespace

dyld: Symbol not found: _uv_loop_init
  Referenced from: <full path here>lib/libisc.1701.dylib
  Expected in: flat namespace


So, it has something to do with flat namespaces vs. two level namespaces. I have tried to add the linker option per macOS documentation as LDFLAGS='-flat_namespace -force_flat_namespace’ but the executables and libraries still have to level namespaces

Tried to force lib to have flat level as well

otool -hV  <full path here>/lib/libuv.dylib                                             

Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    14       1640   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS


otool -hV <full path here>/lib/libisc.1701.dylib
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1952   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS MH_HAS_TLV_DESCRIPTORS


Can problem #1 fixed in source?
Does anyone have any idea how fix #2?


Thanks,


Eddy







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200428/073a63f9/attachment-0001.htm>


More information about the bind-users mailing list