Symbol Collision between ulogd and jansson

Symbol Collision between ulogd and jansson

[조홍식/책임연구원/SW Security개발실 SW Security TP]

The issue I would like to bring to your attention is as follows:
We are using the JSON feature in the PACKAGECONFIG of ulogd, and we have discovered that both ulogd and jansson have methods with the same name, which can lead to a symbol reference error resulting in a segmentation fault.
The method in question is hashtable_del(). 
Based on our backtrace analysis, it appears that when ulogd's hashtable_del() is executed instead of jansson's hashtable_del(), it leads to a segmentation fault (SEGV).
To avoid this symbol collision, I modified ulogd's hashtable_del() to hashtable_delete(), and I have confirmed that this resolves the issue. 

For your reference, 
1. Our backtrace analysis
(gdb) bt
#0  0x000000558ed47730 in __llist_del (next=0x3433326335357830, prev=0x30623663) at /usr/src/debug/ulogd2/2.0.8+git/include/ulogd/linuxlist.h:107
#1  llist_del (entry=0x7fc5c38460) at /usr/src/debug/ulogd2/2.0.8+git/include/ulogd/linuxlist.h:119
#2  hashtable_del (table=table@entry=0x7fc5c38530, n=n@entry=0x7fc5c38460) at /usr/src/debug/ulogd2/2.0.8+git/src/hash.c:96
#3  0x0000007f95234600 in do_dump (json=0x55c234c6b0, flags=0, depth=0, parents=0x7fc5c38530, dump=0x7f95233ad0 <dump_to_strbuffer>, data=0x7fc5c385b0) at /usr/src/debug/jansson/2.14/src/dump.c:416
#4  0x0000007f952348e4 in json_dump_callback (json=json@entry=0x55c234c6b0, callback=callback@entry=0x7f95233ad0 <dump_to_strbuffer>, data=data@entry=0x7fc5c385b0, flags=flags@entry=0) at /usr/src/debug/jansson/2.14/src/dump.c:486
#5  0x0000007f952349a0 in json_dumps (json=json@entry=0x55c234c6b0, flags=flags@entry=0) at /usr/src/debug/jansson/2.14/src/dump.c:433
#6  0x0000007f95271934 in json_interp (upi=0x55c2358690) at /usr/src/debug/ulogd2/2.0.8+git/output/ulogd_output_JSON.c:399

I think this hashtable_del() should be 
https://github.com/akheron/jansson/blob/v2.14/src/hashtable.c#L275  ( jansson's hashtable_del )
But #2 says that the hashtable_del() is ulogd2's one. https://github.com/inliniac/ulogd2/blob/master/src/hash.c#L94  ( ulogd's hashtable_del )

2.  I have included the patch details below:
---
 include/ulogd/hash.h            | 2 +-
 input/flow/ulogd_inpflow_NFCT.c | 4 ++--
 src/hash.c                      | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/ulogd/hash.h b/include/ulogd/hash.h
index d4aedb8..4b4874b 100644
--- a/include/ulogd/hash.h
+++ b/include/ulogd/hash.h
@@ -34,7 +34,7 @@ void hashtable_destroy(struct hashtable *h);
 int hashtable_hash(const struct hashtable *table, const void *data);
 struct hashtable_node *hashtable_find(const struct hashtable *table, const void *data, int id);
 int hashtable_add(struct hashtable *table, struct hashtable_node *n, int id);
-void hashtable_del(struct hashtable *table, struct hashtable_node *node);
+void hashtable_delete(struct hashtable *table, struct hashtable_node *node);
 int hashtable_flush(struct hashtable *table);
 int hashtable_iterate(struct hashtable *table, void *data,
                  int (*iterate)(void *data, void *n));
diff --git a/input/flow/ulogd_inpflow_NFCT.c b/input/flow/ulogd_inpflow_NFCT.c
index 899b7e3..38baf05 100644
--- a/input/flow/ulogd_inpflow_NFCT.c
+++ b/input/flow/ulogd_inpflow_NFCT.c
@@ -702,7 +702,7 @@ event_handler_hashtable(enum nf_conntrack_msg_type type,
            if (ts) {
                  set_timestamp_from_ct(ts, ct, STOP);
                  do_propagate_ct(upi, ct, type, ts);
-                 hashtable_del(cpi->ct_active, &ts->hashnode);
+                 hashtable_delete(cpi->ct_active, &ts->hashnode);
                  nfct_destroy(ts->ct);
                  free(ts);
            } else {
@@ -886,7 +886,7 @@ static int do_purge(void *data1, void *data2)
      ret = nfct_query(cpi->pgh, NFCT_Q_GET, ts->ct);
      if (ret == -1 && errno == ENOENT) {
            do_propagate_ct(upi, ts->ct, NFCT_T_DESTROY, ts);
-           hashtable_del(cpi->ct_active, &ts->hashnode);
+           hashtable_delete(cpi->ct_active, &ts->hashnode);
            nfct_destroy(ts->ct);
            free(ts);
      }
diff --git a/src/hash.c b/src/hash.c
index 1d99130..8fd98a1 100644
--- a/src/hash.c
+++ b/src/hash.c
@@ -91,7 +91,7 @@ int hashtable_add(struct hashtable *table, struct hashtable_node *n, int id)
      return 0;
 }
 
-void hashtable_del(struct hashtable *table, struct hashtable_node *n)
+void hashtable_delete(struct hashtable *table, struct hashtable_node *n)
 {
      llist_del(&n->head);
      table->count--;

Re: Symbol Collision between ulogd and jansson

[Pablo Neira Ayuso]

Hi,

On Mon, Jan 13, 2025 at 06:41:19AM +0000, 조홍식/책임연구원/SW Security개발실 SW Security TP wrote:
> The issue I would like to bring to your attention is as follows: We
> are using the JSON feature in the PACKAGECONFIG of ulogd, and we
> have discovered that both ulogd and jansson have methods with the
> same name, which can lead to a symbol reference error resulting in a
> segmentation fault.  The method in question is hashtable_del().
> Based on our backtrace analysis, it appears that when ulogd's
> hashtable_del() is executed instead of jansson's hashtable_del(), it
> leads to a segmentation fault (SEGV).
> To avoid this symbol collision, I modified ulogd's hashtable_del()
> to hashtable_delete(), and I have confirmed that this resolves the
> issue.

$ nm -D libjansson.so.4 | grep hashtable_del
$

Are you building a static binary? Otherwise, I don't see how the clash
is going on.

I am fine with this patch, would you submit it using git format-patch
and including Signed-off-by:?

Thanks.

Re: Symbol Collision between ulogd and jansson

[조홍식/책임연구원/SW Security개발실 SW Security TP]

Here is the result of finding symbols in ulogd and libjansson.

$ nm -D libjansson.so | grep hashtable_del
0000000000005b50 T hashtable_del@@JANSSON_4

$ nm ulogd | grep hashtable_del
0000000000007704 T hashtable_del

We did not build it as a static library.
Like you mentioned, I also do not know the exact reason why a SEGV occurs in this case.
However, I have confirmed through sources like GPT that symbol collisions can occur in such situations (the possibility of symbol collisions due to the loading order of libraries).

Answers of GPT:
Therefore, even if a symbol version like hashtable_del@@JANSSON_4 exists, if a symbol with the same name is defined in another library, a symbol collision can still occur.
In such cases, which symbol gets called will depend on factors such as library load order, version information, and environment variable settings.

Anyway, I'll update the patch (including Signed-off-by: ) in next reply to divide the content.

________________________________________
보낸 사람: Pablo Neira Ayuso <pablo@netfilter.org>
보낸 날짜: 2025년 1월 14일 화요일 오전 7:23
받는 사람: 조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com>
참조: netfilter-devel@vger.kernel.org <netfilter-devel@vger.kernel.org>; 손영섭/책임연구원/SW Security개발실 SW Security TP <loth.son@lge.com>; 남정주/책임연구원/SW Security개발실 SW Security TP <jungjoo.nahm@lge.com>; 정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task <jaeyoon.jung@lge.com>
제목: Re: Symbol Collision between ulogd and jansson
 
Hi,

On Mon, Jan 13, 2025 at 06:41:19AM +0000, 조홍식/책임연구원/SW Security개발실 SW Security TP wrote:
> The issue I would like to bring to your attention is as follows: We
> are using the JSON feature in the PACKAGECONFIG of ulogd, and we
> have discovered that both ulogd and jansson have methods with the
> same name, which can lead to a symbol reference error resulting in a
> segmentation fault.  The method in question is hashtable_del().
> Based on our backtrace analysis, it appears that when ulogd's
> hashtable_del() is executed instead of jansson's hashtable_del(), it
> leads to a segmentation fault (SEGV).
> To avoid this symbol collision, I modified ulogd's hashtable_del()
> to hashtable_delete(), and I have confirmed that this resolves the
> issue.

$ nm -D libjansson.so.4 | grep hashtable_del
$

Are you building a static binary? Otherwise, I don't see how the clash
is going on.

I am fine with this patch, would you submit it using git format-patch
and including Signed-off-by:?

Thanks.

Re: Symbol Collision between ulogd and jansson

[조홍식/책임연구원/SW Security개발실 SW Security TP]

From 23bbb5a2ece807b93edf37863624133e20b511d5 Mon Sep 17 00:00:00 2001
From: "hongsik.jo" <hongsik.jo@lge.com>
Date: Thu, 9 Jan 2025 13:41:18 +0900
Subject: [PATCH] Avoid symbol collision between ulogd and jansson.

hastable_del() is both existed in ulogd and jansson.
And it can causes symbol collision, try to avoid it.

Signed-off-by: hongsik.jo <hongsik.jo@lge.com>
---
 include/ulogd/hash.h            | 2 +-
 input/flow/ulogd_inpflow_NFCT.c | 4 ++--
 src/hash.c                      | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/ulogd/hash.h b/include/ulogd/hash.h
index d4aedb8..4b4874b 100644
--- a/include/ulogd/hash.h
+++ b/include/ulogd/hash.h
@@ -34,7 +34,7 @@ void hashtable_destroy(struct hashtable *h);
 int hashtable_hash(const struct hashtable *table, const void *data);
 struct hashtable_node *hashtable_find(const struct hashtable *table, const void *data, int id);
 int hashtable_add(struct hashtable *table, struct hashtable_node *n, int id);
-void hashtable_del(struct hashtable *table, struct hashtable_node *node);
+void hashtable_delete(struct hashtable *table, struct hashtable_node *node);
 int hashtable_flush(struct hashtable *table);
 int hashtable_iterate(struct hashtable *table, void *data,
                      int (*iterate)(void *data, void *n));
diff --git a/input/flow/ulogd_inpflow_NFCT.c b/input/flow/ulogd_inpflow_NFCT.c
index 899b7e3..38baf05 100644
--- a/input/flow/ulogd_inpflow_NFCT.c
+++ b/input/flow/ulogd_inpflow_NFCT.c
@@ -702,7 +702,7 @@ event_handler_hashtable(enum nf_conntrack_msg_type type,
                if (ts) {
                        set_timestamp_from_ct(ts, ct, STOP);
                        do_propagate_ct(upi, ct, type, ts);
-                       hashtable_del(cpi->ct_active, &ts->hashnode);
+                       hashtable_delete(cpi->ct_active, &ts->hashnode);
                        nfct_destroy(ts->ct);
                        free(ts);
                } else {
@@ -886,7 +886,7 @@ static int do_purge(void *data1, void *data2)
        ret = nfct_query(cpi->pgh, NFCT_Q_GET, ts->ct);
        if (ret == -1 && errno == ENOENT) {
                do_propagate_ct(upi, ts->ct, NFCT_T_DESTROY, ts);
-               hashtable_del(cpi->ct_active, &ts->hashnode);
+               hashtable_delete(cpi->ct_active, &ts->hashnode);
                nfct_destroy(ts->ct);
                free(ts);
        }
diff --git a/src/hash.c b/src/hash.c
index 1d99130..8fd98a1 100644
--- a/src/hash.c
+++ b/src/hash.c
@@ -91,7 +91,7 @@ int hashtable_add(struct hashtable *table, struct hashtable_node *n, int id)
        return 0;
 }

-void hashtable_del(struct hashtable *table, struct hashtable_node *n)
+void hashtable_delete(struct hashtable *table, struct hashtable_node *n)
 {
        llist_del(&n->head);
        table->count--;
--
2.34.1

________________________________________
보낸 사람: 조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com>
보낸 날짜: 2025년 1월 14일 화요일 오후 2:00
받는 사람: Pablo Neira Ayuso <pablo@netfilter.org>
참조: netfilter-devel@vger.kernel.org <netfilter-devel@vger.kernel.org>; 손영섭/책임연구원/SW Security개발실 SW Security TP <loth.son@lge.com>; 남정주/책임연구원/SW Security개발실 SW Security TP <jungjoo.nahm@lge.com>; 정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task <jaeyoon.jung@lge.com>; 조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com>
제목: Re: Symbol Collision between ulogd and jansson
 
Here is the result of finding symbols in ulogd and libjansson.

$ nm -D libjansson.so | grep hashtable_del
0000000000005b50 T hashtable_del@@JANSSON_4

$ nm ulogd | grep hashtable_del
0000000000007704 T hashtable_del

We did not build it as a static library.
Like you mentioned, I also do not know the exact reason why a SEGV occurs in this case.
However, I have confirmed through sources like GPT that symbol collisions can occur in such situations (the possibility of symbol collisions due to the loading order of libraries).

Answers of GPT:
Therefore, even if a symbol version like hashtable_del@@JANSSON_4 exists, if a symbol with the same name is defined in another library, a symbol collision can still occur.
In such cases, which symbol gets called will depend on factors such as library load order, version information, and environment variable settings.

Anyway, I'll update the patch (including Signed-off-by: ) in next reply to divide the content.

________________________________________
보낸 사람: Pablo Neira Ayuso <pablo@netfilter.org>
보낸 날짜: 2025년 1월 14일 화요일 오전 7:23
받는 사람: 조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com>
참조: netfilter-devel@vger.kernel.org <netfilter-devel@vger.kernel.org>; 손영섭/책임연구원/SW Security개발실 SW Security TP <loth.son@lge.com>; 남정주/책임연구원/SW Security개발실 SW Security TP <jungjoo.nahm@lge.com>; 정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task <jaeyoon.jung@lge.com>
제목: Re: Symbol Collision between ulogd and jansson
 
Hi,

On Mon, Jan 13, 2025 at 06:41:19AM +0000, 조홍식/책임연구원/SW Security개발실 SW Security TP wrote:
> The issue I would like to bring to your attention is as follows: We
> are using the JSON feature in the PACKAGECONFIG of ulogd, and we
> have discovered that both ulogd and jansson have methods with the
> same name, which can lead to a symbol reference error resulting in a
> segmentation fault.  The method in question is hashtable_del().
> Based on our backtrace analysis, it appears that when ulogd's
> hashtable_del() is executed instead of jansson's hashtable_del(), it
> leads to a segmentation fault (SEGV).
> To avoid this symbol collision, I modified ulogd's hashtable_del()
> to hashtable_delete(), and I have confirmed that this resolves the
> issue.

$ nm -D libjansson.so.4 | grep hashtable_del
$

Are you building a static binary? Otherwise, I don't see how the clash
is going on.

I am fine with this patch, would you submit it using git format-patch
and including Signed-off-by:?

Thanks.

Re: Symbol Collision between ulogd and jansson

[Florian Westphal]

조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com> wrote:
> The issue I would like to bring to your attention is as follows:
> We are using the JSON feature in the PACKAGECONFIG of ulogd, and we have discovered that both ulogd and jansson have methods with the same name, which can lead to a symbol reference error resulting in a segmentation fault.
> The method in question is hashtable_del(). 
> Based on our backtrace analysis, it appears that when ulogd's hashtable_del() is executed instead of jansson's hashtable_del(), it leads to a segmentation fault (SEGV).
> To avoid this symbol collision, I modified ulogd's hashtable_del() to hashtable_delete(), and I have confirmed that this resolves the issue. 
> 
> For your reference, 
> 1. Our backtrace analysis
> (gdb) bt
> #0  0x000000558ed47730 in __llist_del (next=0x3433326335357830, prev=0x30623663) at /usr/src/debug/ulogd2/2.0.8+git/include/ulogd/linuxlist.h:107
> #1  llist_del (entry=0x7fc5c38460) at /usr/src/debug/ulogd2/2.0.8+git/include/ulogd/linuxlist.h:119
> #2  hashtable_del (table=table@entry=0x7fc5c38530, n=n@entry=0x7fc5c38460) at /usr/src/debug/ulogd2/2.0.8+git/src/hash.c:96
> #3  0x0000007f95234600 in do_dump (json=0x55c234c6b0, flags=0, depth=0, parents=0x7fc5c38530, dump=0x7f95233ad0 <dump_to_strbuffer>, data=0x7fc5c385b0) at /usr/src/debug/jansson/2.14/src/dump.c:416
> #4  0x0000007f952348e4 in json_dump_callback (json=json@entry=0x55c234c6b0, callback=callback@entry=0x7f95233ad0 <dump_to_strbuffer>, data=data@entry=0x7fc5c385b0, flags=flags@entry=0) at /usr/src/debug/jansson/2.14/src/dump.c:486
> #5  0x0000007f952349a0 in json_dumps (json=json@entry=0x55c234c6b0, flags=flags@entry=0) at /usr/src/debug/jansson/2.14/src/dump.c:433
> #6  0x0000007f95271934 in json_interp (upi=0x55c2358690) at /usr/src/debug/ulogd2/2.0.8+git/output/ulogd_output_JSON.c:399
> 
> I think this hashtable_del() should be 
> https://github.com/akheron/jansson/blob/v2.14/src/hashtable.c#L275  ( jansson's hashtable_del )
> But #2 says that the hashtable_del() is ulogd2's one. https://github.com/inliniac/ulogd2/blob/master/src/hash.c#L94  ( ulogd's hashtable_del )
>

Uhm.  What jansson version are you using?

commit 7c707a73a2251c20afaecc028267b99d0ee60184
Author: Petri Lehtinen <petri@digip.org>
Date:   Sun Nov 29 13:04:00 2009 +0200

    Only export symbols starting with "json_" in libjansson.la

    This way we don't pollute the symbol namespace with internal symbols.

Re: Symbol Collision between ulogd and jansson

[정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task]

Hi,

It's 2.14 being built with CMake.
It looks like '-export-symbols-regex' isn't set with CMake.


Best regards,
---
Jaeyoon Jung
Software Platform Lab. / Corporate R&D / LG Electronics Inc.


________________________________________
From: Florian Westphal <fw@strlen.de>
Sent: Tuesday, January 14, 2025 7:41 PM
To: 조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com>
Cc: netfilter-devel@vger.kernel.org <netfilter-devel@vger.kernel.org>; 손영섭/책임연구원/SW Security개발실 SW Security TP <loth.son@lge.com>; 남정주/책임연구원/SW Security개발실 SW Security TP <jungjoo.nahm@lge.com>; 정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task <jaeyoon.jung@lge.com>
Subject: Re: Symbol Collision between ulogd and jansson
 
조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com> wrote:
> The issue I would like to bring to your attention is as follows:
> We are using the JSON feature in the PACKAGECONFIG of ulogd, and we have discovered that both ulogd and jansson have methods with the same name, which can lead to a symbol reference error resulting in a segmentation fault.
> The method in question is hashtable_del().
> Based on our backtrace analysis, it appears that when ulogd's hashtable_del() is executed instead of jansson's hashtable_del(), it leads to a segmentation fault (SEGV).
> To avoid this symbol collision, I modified ulogd's hashtable_del() to hashtable_delete(), and I have confirmed that this resolves the issue.
>
> For your reference,
> 1. Our backtrace analysis
> (gdb) bt
> #0  0x000000558ed47730 in __llist_del (next=0x3433326335357830, prev=0x30623663) at /usr/src/debug/ulogd2/2.0.8+git/include/ulogd/linuxlist.h:107
> #1  llist_del (entry=0x7fc5c38460) at /usr/src/debug/ulogd2/2.0.8+git/include/ulogd/linuxlist.h:119
> #2  hashtable_del (table=table@entry=0x7fc5c38530, n=n@entry=0x7fc5c38460) at /usr/src/debug/ulogd2/2.0.8+git/src/hash.c:96
> #3  0x0000007f95234600 in do_dump (json=0x55c234c6b0, flags=0, depth=0, parents=0x7fc5c38530, dump=0x7f95233ad0 <dump_to_strbuffer>, data=0x7fc5c385b0) at /usr/src/debug/jansson/2.14/src/dump.c:416
> #4  0x0000007f952348e4 in json_dump_callback (json=json@entry=0x55c234c6b0, callback=callback@entry=0x7f95233ad0 <dump_to_strbuffer>, data=data@entry=0x7fc5c385b0, flags=flags@entry=0) at /usr/src/debug/jansson/2.14/src/dump.c:486
> #5  0x0000007f952349a0 in json_dumps (json=json@entry=0x55c234c6b0, flags=flags@entry=0) at /usr/src/debug/jansson/2.14/src/dump.c:433
> #6  0x0000007f95271934 in json_interp (upi=0x55c2358690) at /usr/src/debug/ulogd2/2.0.8+git/output/ulogd_output_JSON.c:399
>
> I think this hashtable_del() should be
> https://github.com/akheron/jansson/blob/v2.14/src/hashtable.c#L275  ( jansson's hashtable_del )
> But #2 says that the hashtable_del() is ulogd2's one. https://github.com/inliniac/ulogd2/blob/master/src/hash.c#L94  ( ulogd's hashtable_del )
>

Uhm.  What jansson version are you using?

commit 7c707a73a2251c20afaecc028267b99d0ee60184
Author: Petri Lehtinen <petri@digip.org>
Date:   Sun Nov 29 13:04:00 2009 +0200

    Only export symbols starting with "json_" in libjansson.la

    This way we don't pollute the symbol namespace with internal symbols.

Re: Symbol Collision between ulogd and jansson

[Florian Westphal]

정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task <jaeyoon.jung@lge.com> wrote:
> Hi,
> 
> It's 2.14 being built with CMake.
> It looks like '-export-symbols-regex' isn't set with CMake.

Can you file a report with jansson? Libraries should not pollute
the namespace like this.  I can confirm that its fine with autotools
but cmake generated .so has everyting exported :-(

[ I also find it very questionable to have two build systems; it
makes these bugs harder to find for everyone, but thats a
different issue ].

Re: Symbol Collision between ulogd and jansson

[조홍식/책임연구원/SW Security개발실 SW Security TP]

> Libraries should not pollute the namespace like this.
I completely agree with your opinion.
As you mentioned, I checked the only Cmake build has the problem. And It is the approprate to fix in jansson. I'll try to report it to jansson.

I believe that it could be reasonable approach avoding duplicated naming when such explicit symbol collisions are recognized, regardless of whether you are a library user or maintainer. But it's not a mandatory and up to you.

________________________________________
보낸 사람: Florian Westphal <fw@strlen.de>
보낸 날짜: 2025년 1월 14일 화요일 오후 10:32
받는 사람: 정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task <jaeyoon.jung@lge.com>
참조: Florian Westphal <fw@strlen.de>; 조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com>; netfilter-devel@vger.kernel.org <netfilter-devel@vger.kernel.org>; 손영섭/책임연구원/SW Security개발실 SW Security TP <loth.son@lge.com>; 남정주/책임연구원/SW Security개발실 SW Security TP <jungjoo.nahm@lge.com>
제목: Re: Symbol Collision between ulogd and jansson
 
정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task <jaeyoon.jung@lge.com> wrote:
> Hi,
>
> It's 2.14 being built with CMake.
> It looks like '-export-symbols-regex' isn't set with CMake.

Can you file a report with jansson? Libraries should not pollute
the namespace like this.  I can confirm that its fine with autotools
but cmake generated .so has everyting exported :-(

[ I also find it very questionable to have two build systems; it
makes these bugs harder to find for everyone, but thats a
different issue ].

Re: Symbol Collision between ulogd and jansson

[Florian Westphal]

조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com> wrote:
> > Libraries should not pollute the namespace like this.
> I completely agree with your opinion.
> As you mentioned, I checked the only Cmake build has the problem. And It is the approprate to fix in jansson. I'll try to report it to jansson.
> 
> I believe that it could be reasonable approach avoding duplicated naming when such explicit symbol collisions are recognized, regardless of whether you are a library user or maintainer. But it's not a mandatory and up to you.

Sure, but if you assume libraries that export generic names, then
both hashtable_del or hashtable_delete could clash in the future.

If anything, we need to prefix *ALL* non-static functions with
ulogd_ or similar, which is huge churn and should not be needed
given ulogd isn't a library, i.e. all applications in existence
would have to do it.

And it would still be a problem in jansson.