Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

[Waqar Hameed]

On Tue, Mar 05, 2024 at 23:11 +0800 kernel test robot <lkp@intel.com> wrote:

> Hi Vincent,
>
> FYI, the error/warning still remains.
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   90d35da658da8cff0d4ecbb5113f5fac9d00eb72
> commit: 10f4c9b9a33b7df000f74fa0d896351fb1a61e6a x86/asm: Fix build of UML with KASAN
> date:   6 months ago
> config: um-randconfig-r111-20240305 (https://download.01.org/0day-ci/archive/20240305/202403052336.y6DkUd8a-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240305/202403052336.y6DkUd8a-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202403052336.y6DkUd8a-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>    /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_write':
>>> pcap-dbus.o:(.text+0x244ff): undefined reference to `dbus_message_demarshal'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24515): undefined reference to `dbus_connection_send'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2451e): undefined reference to `dbus_connection_flush'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24526): undefined reference to `dbus_message_unref'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24574): undefined reference to `dbus_error_free'
>    /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_read':
>>> pcap-dbus.o:(.text+0x245c0): undefined reference to `dbus_connection_pop_message'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245e2): undefined reference to `dbus_connection_pop_message'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245f8): undefined reference to `dbus_connection_read_write'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24662): undefined reference to `dbus_message_is_signal'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2467e): undefined reference to `dbus_message_marshal'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x246e6): undefined reference to `dbus_free'
>    /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_cleanup':
>>> pcap-dbus.o:(.text+0x2474c): undefined reference to `dbus_connection_unref'
>    /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_activate':
>>> pcap-dbus.o:(.text+0x247f6): undefined reference to `dbus_connection_open'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2480e): undefined reference to `dbus_bus_register'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x248fc): undefined reference to `dbus_bus_add_match'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24904): undefined reference to `dbus_error_is_set'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2494b): undefined reference to `dbus_bus_get'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x2497c): undefined reference to `dbus_error_free'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x2498d): undefined reference to `dbus_bus_add_match'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x24995): undefined reference to `dbus_error_is_set'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x249ce): undefined reference to `dbus_error_free'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x249da): undefined reference to `dbus_connection_unref'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x24a06): undefined reference to `dbus_bus_get'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x24a42): undefined reference to `dbus_error_free'
>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a55): undefined reference to `dbus_connection_set_max_received_size'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x24a66): undefined reference to `dbus_connection_unref'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x24adc): undefined reference to `dbus_error_free'
>    /usr/bin/ld: pcap-dbus.o:(.text+0x24b1a): undefined reference to `dbus_error_free'
>    collect2: error: ld returned 1 exit status

Hi Ingo!

This error seems to be unrelated to the reported commit 10f4c9b9a33b
("x86/asm: Fix build of UML with KASAN"). The root cause seems to be the
option `CONFIG_UML_NET_PCAP` (which is deprecated, as stated in
`arch/um/drivers/Kconfig`), which tries to build `pcap.o`. 

In the Makefile, one can find

  LDFLAGS_pcap.o = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libpcap.a)
  
and at the top the very old comment

 # pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked
 # in to pcap.o

`libpcap` is indeed the one referencing these symbols (that can be found
in `libdbus-1` and `libsystemd`). I'm guessing we should just ignore
this report, right? (Can it even be disabled somehow?)

Thank you
Waqar Hameed

P.S 
Vincent has left the company and has therefore been removed from
the CC list.
D.S

Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

[Anton Ivanov]

On 06/03/2024 16:14, Waqar Hameed wrote:
> On Tue, Mar 05, 2024 at 23:11 +0800 kernel test robot <lkp@intel.com> wrote:
> 
>> Hi Vincent,
>>
>> FYI, the error/warning still remains.
>>
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> head:   90d35da658da8cff0d4ecbb5113f5fac9d00eb72
>> commit: 10f4c9b9a33b7df000f74fa0d896351fb1a61e6a x86/asm: Fix build of UML with KASAN
>> date:   6 months ago
>> config: um-randconfig-r111-20240305 (https://download.01.org/0day-ci/archive/20240305/202403052336.y6DkUd8a-lkp@intel.com/config)
>> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240305/202403052336.y6DkUd8a-lkp@intel.com/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp@intel.com>
>> | Closes: https://lore.kernel.org/oe-kbuild-all/202403052336.y6DkUd8a-lkp@intel.com/
>>
>> All errors (new ones prefixed by >>):
>>
>>     /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_write':
>>>> pcap-dbus.o:(.text+0x244ff): undefined reference to `dbus_message_demarshal'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24515): undefined reference to `dbus_connection_send'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2451e): undefined reference to `dbus_connection_flush'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24526): undefined reference to `dbus_message_unref'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24574): undefined reference to `dbus_error_free'
>>     /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_read':
>>>> pcap-dbus.o:(.text+0x245c0): undefined reference to `dbus_connection_pop_message'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245e2): undefined reference to `dbus_connection_pop_message'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x245f8): undefined reference to `dbus_connection_read_write'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24662): undefined reference to `dbus_message_is_signal'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2467e): undefined reference to `dbus_message_marshal'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x246e6): undefined reference to `dbus_free'
>>     /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_cleanup':
>>>> pcap-dbus.o:(.text+0x2474c): undefined reference to `dbus_connection_unref'
>>     /usr/bin/ld: arch/um/drivers/pcap.o: in function `dbus_activate':
>>>> pcap-dbus.o:(.text+0x247f6): undefined reference to `dbus_connection_open'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2480e): undefined reference to `dbus_bus_register'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x248fc): undefined reference to `dbus_bus_add_match'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24904): undefined reference to `dbus_error_is_set'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x2494b): undefined reference to `dbus_bus_get'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x2497c): undefined reference to `dbus_error_free'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x2498d): undefined reference to `dbus_bus_add_match'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x24995): undefined reference to `dbus_error_is_set'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x249ce): undefined reference to `dbus_error_free'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x249da): undefined reference to `dbus_connection_unref'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x24a06): undefined reference to `dbus_bus_get'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x24a42): undefined reference to `dbus_error_free'
>>>> /usr/bin/ld: pcap-dbus.o:(.text+0x24a55): undefined reference to `dbus_connection_set_max_received_size'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x24a66): undefined reference to `dbus_connection_unref'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x24adc): undefined reference to `dbus_error_free'
>>     /usr/bin/ld: pcap-dbus.o:(.text+0x24b1a): undefined reference to `dbus_error_free'
>>     collect2: error: ld returned 1 exit status
> 
> Hi Ingo!
> 
> This error seems to be unrelated to the reported commit 10f4c9b9a33b
> ("x86/asm: Fix build of UML with KASAN"). The root cause seems to be the
> option `CONFIG_UML_NET_PCAP` (which is deprecated, as stated in
> `arch/um/drivers/Kconfig`), which tries to build `pcap.o`.
> 
> In the Makefile, one can find
> 
>    LDFLAGS_pcap.o = $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libpcap.a)
>    
> and at the top the very old comment
> 
>   # pcap is broken in 2.5 because kbuild doesn't allow pcap.a to be linked
>   # in to pcap.o
> 
> `libpcap` is indeed the one referencing these symbols (that can be found
> in `libdbus-1` and `libsystemd`). I'm guessing we should just ignore
> this report, right? (Can it even be disabled somehow?)
> 
> Thank you
> Waqar Hameed
> 
> P.S
> Vincent has left the company and has therefore been removed from
> the CC list.
> D.S
>


PCAP is not feasible to incorporate into the build system at present.
It has grown all kinds of warts over the years and brings a lot of dependencies.
IMHO we should remove it from the tree. It has reached a point where it cannot
be built on a modern system.

The users who need the same functionality can produce a bpf filter using tcpdump
and load it as "firmware" into the vector/raw driver.

I am working on a pure python bpf compiler which takes the same syntax as PCAP.
It is showing signs of life and it can do some of the simpler use cases. Once
that is ready, it should be possible to use that instead of pcap/tcpdump.

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

[Johannes Berg]

On Thu, 2024-03-07 at 09:54 +0000, Anton Ivanov wrote:
> 
> PCAP is not feasible to incorporate into the build system at present.
> It has grown all kinds of warts over the years and brings a lot of dependencies.
> IMHO we should remove it from the tree. It has reached a point where it cannot
> be built on a modern system.

I suppose it might be possible to call pcap-config? But agree that it
doesn't seem really worth investing in.

> The users who need the same functionality can produce a bpf filter using tcpdump
> and load it as "firmware" into the vector/raw driver.
> 
> I am working on a pure python bpf compiler which takes the same syntax as PCAP.
> It is showing signs of life and it can do some of the simpler use cases. Once
> that is ready, it should be possible to use that instead of pcap/tcpdump.

How's that required to be formatted and loaded? tcpdump itself can also
dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
so probably not useful). Perhaps we could even automatically call
'tcpdump' at runtime?

johannes

Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

[Anton Ivanov]

On 07/03/2024 10:03, Johannes Berg wrote:
> On Thu, 2024-03-07 at 09:54 +0000, Anton Ivanov wrote:
>>
>> PCAP is not feasible to incorporate into the build system at present.
>> It has grown all kinds of warts over the years and brings a lot of dependencies.
>> IMHO we should remove it from the tree. It has reached a point where it cannot
>> be built on a modern system.
> 
> I suppose it might be possible to call pcap-config? But agree that it
> doesn't seem really worth investing in.
> 
>> The users who need the same functionality can produce a bpf filter using tcpdump
>> and load it as "firmware" into the vector/raw driver.
>>
>> I am working on a pure python bpf compiler which takes the same syntax as PCAP.
>> It is showing signs of life and it can do some of the simpler use cases. Once
>> that is ready, it should be possible to use that instead of pcap/tcpdump.
> 
> How's that required to be formatted and loaded? tcpdump itself can also
> dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
> so probably not useful). Perhaps we could even automatically call
> 'tcpdump' at runtime?

That is one option.

As far as common use cases are concerned, at present you can:

tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=

It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.

I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
standard - it is also used by iptables, etc. It can used by other code generators as well.

> 
> johannes
> 

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

[Johannes Berg]

On Thu, 2024-03-07 at 10:27 +0000, Anton Ivanov wrote:
> > 
> > How's that required to be formatted and loaded? tcpdump itself can also
> > dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
> > so probably not useful). Perhaps we could even automatically call
> > 'tcpdump' at runtime?
> 
> That is one option.
> 
> As far as common use cases are concerned, at present you can:
> 
> tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=
> 
> It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.
> 
> I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
> standard - it is also used by iptables, etc. It can used by other code generators as well.

Yeah, that makes sense, this is all kind of special configuration
anyway, and given that it's been broken forever ...

I actually doubt anyone would scream if we just removed it, so maybe
just remove it and if they do scream, point to the above, including said
3-liner in the response?

johannes

Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

[Anton Ivanov]

On 07/03/2024 10:29, Johannes Berg wrote:
> On Thu, 2024-03-07 at 10:27 +0000, Anton Ivanov wrote:
>>>
>>> How's that required to be formatted and loaded? tcpdump itself can also
>>> dump the filter in BPF format, with -d/-ddd (-dd is a C representation,
>>> so probably not useful). Perhaps we could even automatically call
>>> 'tcpdump' at runtime?
>>
>> That is one option.
>>
>> As far as common use cases are concerned, at present you can:
>>
>> tcpdump -ddd, convert it to raw binary (3 liner in a language of choice) and pass that to vecX as a bpffile=
>>
>> It may be worth it to make vecX also take the -ddd format directly by adding "format" options to bpffile.
>>
>> I'd rather do that instead of invoking tcpdump out of a device open. The -ddd notation (+/- a comma here and there) is
>> standard - it is also used by iptables, etc. It can used by other code generators as well.
> 
> Yeah, that makes sense, this is all kind of special configuration
> anyway, and given that it's been broken forever ...
> 
> I actually doubt anyone would scream if we just removed it, so maybe
> just remove it and if they do scream, point to the above, including said
> 3-liner in the response?

Let's make it so.

> 
> johannes
> 
> 

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Re: pcap-dbus.o:undefined reference to `dbus_message_demarshal'

[Waqar Hameed]

On Thu, Mar 07, 2024 at 10:49 +0000 Anton Ivanov <anton.ivanov@cambridgegreys.com> wrote:

> On 07/03/2024 10:29, Johannes Berg wrote:

[...]

>> Yeah, that makes sense, this is all kind of special configuration
>> anyway, and given that it's been broken forever ...
>> I actually doubt anyone would scream if we just removed it, so maybe
>> just remove it and if they do scream, point to the above, including said
>> 3-liner in the response?
>
> Let's make it so.

I'm guessing Johannes (or Anton) will create the patch for removing it
and no further action is needed from my side.

Thank you for your swift responses!