[jira] [Commented] (ZOOKEEPER-4014) libzookeeper.a not properly linking to libhashtable.a

["Damien Diederen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237285#comment-17237285 ] 

Damien Diederen commented on ZOOKEEPER-4014:
--------------------------------------------

Hi [~Fraser],

I have added a comment to your [PR 1546|https://github.com/apache/zookeeper/pull/1546#discussion_r528586472] which is relevant to this.

It includes a "quick fix," but solving this correctly requires a bit of thought; It may be that getting rid of {{libhashtable.a}} (and storing these objects in {{libzookeeper.a}}, as you do above) is the correct solution for the CMake pipeline.

We might want to produce shared objects (or DLLs) instead/in addition to archives.



> libzookeeper.a not properly linking to libhashtable.a
> -----------------------------------------------------
>
>                 Key: ZOOKEEPER-4014
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4014
>             Project: ZooKeeper
>          Issue Type: Bug
>            Reporter: B
>            Priority: Minor
>
> Admittedly, there's a high probability that the problem lies between the chair and the keyboard.
> If I do this:
> ```
> ; cd zookeeper-client/zookeeper-client-c
> ; cmake .
> ; make
> ```
> `libzookeeper.a` ends up not having linked to `libhashmap.a`:
> ```
> ; nm libzookeeper.a | grep create_hashtable
>  U _create_hashtable
> ```
> To cover some bases: `libzookeeper.a` has its own symbols, as expected:
> ```
> ; nm libzookeeper.a | grep zookeeper_init
> 0000000000000f70 T _zookeeper_init
> 00000000000016a0 T _zookeeper_init2
> 0000000000000fe0 t _zookeeper_init_internal
> 0000000000001710 T _zookeeper_init_sasl
> ```
> And the sister `libhashtable.a` has symbols of its own:
> ```
> ; nm libhashtable.a | grep create_hashtable
> 0000000000000000 T _create_hashtable
> ```
> And CMakeLists says, to my untrained eyes at least, that libzookeeper.a should be linking to libhashtable.a:
> ```
> target_link_libraries(zookeeper PUBLIC
>  hashtable
> ```
> But I don't see the link actually happening with `make VERBOSE=1`.
> The result is that the generated `libzookeeper.a` just doesn't work.
> I was able to monkey-patch it by doing this:
> ```
> diff --git a/zookeeper-client/zookeeper-client-c/CMakeLists.txt b/zookeeper-client/zookeeper-client-c/CMakeLists.txt
> index e89549d7a..fdefd67e7 100644
> --- a/zookeeper-client/zookeeper-client-c/CMakeLists.txt
> +++ b/zookeeper-client/zookeeper-client-c/CMakeLists.txt
> @@ -196,7 +196,7 @@ if(WIN32)
>  list(APPEND zookeeper_sources src/winport.c)
>  endif()
> -add_library(zookeeper STATIC ${zookeeper_sources})
> +add_library(zookeeper STATIC ${zookeeper_sources} ${hashtable_sources})
>  target_include_directories(zookeeper PUBLIC include ${CMAKE_CURRENT_BINARY_DIR}/include generated)
>  target_link_libraries(zookeeper PUBLIC
>  hashtable
> ```
> That is, by skipping libhashtables.a entirely and just bundling the hashtable.o's directly into libzookeeper.a.  This is a total cop-out, but I couldn't figure out the right cmake incantation to make it work properly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)