Bug 251486 - Malformed libraries
Summary: Malformed libraries
Alias: None
Product: Fedora
Classification: Fedora
Component: libnetfilter_queue   
(Show other bugs)
Version: 7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Paul P Komkoff Jr
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-09 12:17 UTC by Benjamin S. Scarlet
Modified: 2008-02-24 16:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-24 16:56:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Benjamin S. Scarlet 2007-08-09 12:17:48 UTC
Description of problem:
The libnetfilter_queue libraries shipped in Fedora 7 seem not to have built
correctly. Running nm on the libraries shows no symbols, nor does linking
against the libraries resolve symbols to allow executables to be built. 

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1.nm /usr/lib64/libnetfilter_queue.so.1.1.0
Actual results:
nm: /usr/lib64/libnetfilter_queue.so.1.1.0: no symbols

Expected results:
0000000000201888 a _DYNAMIC
0000000000201a10 a _GLOBAL_OFFSET_TABLE_
0000000000201ac8 A __bss_start
0000000000001120 t __build_send_cfg_msg
0000000000000df0 t __nfq_rcv_pkt
0000000000000e50 t __set_verdict
0000000000201ac8 A _edata
0000000000201ad0 A _end
0000000000000c50 t find_qh
                 U free@@GLIBC_2.2.5
                 U malloc@@GLIBC_2.2.5
                 U nfnl_addattr32
                 U nfnl_addattr_l
                 U nfnl_build_nfa_iovec
                 U nfnl_callback_register
                 U nfnl_close
                 U nfnl_fd
                 U nfnl_fill_hdr
                 U nfnl_handle_packet
                 U nfnl_open
                 U nfnl_sendiov
                 U nfnl_subsys_close
                 U nfnl_subsys_open
                 U nfnl_talk
00000000000011e0 T nfq_bind_pf
0000000000001350 T nfq_close
0000000000001270 T nfq_create_queue
0000000000001200 T nfq_destroy_queue
0000000000201ac8 B nfq_errno
0000000000001490 T nfq_fd
0000000000000d70 T nfq_get_indev
0000000000000c90 T nfq_get_msg_packet_hdr
0000000000000dd0 T nfq_get_nfmark
0000000000000d30 T nfq_get_outdev
0000000000000cb0 T nfq_get_packet_hw
0000000000000cd0 T nfq_get_payload
0000000000000d50 T nfq_get_physindev
0000000000000d10 T nfq_get_physoutdev
0000000000000d90 T nfq_get_timestamp
00000000000011f0 T nfq_handle_packet
0000000000000c80 T nfq_nfnlh
0000000000001440 T nfq_open
00000000000013a0 T nfq_open_nfnl
0000000000001070 T nfq_set_mode
0000000000000fe0 T nfq_set_queue_maxlen
0000000000000fc0 T nfq_set_verdict
0000000000000fa0 T nfq_set_verdict_mark
00000000000011d0 T nfq_unbind_pf
0000000000201ab0 d pkt_cb

Additional info:
RPMs I built by hand from the source packages are larger, and contain libraries
with symbols (from which I generated the expected output, above), so presumably
the problem is something unexpected about the official build environment which
is not reproduced on my (fairly vanilla) system.

Comment 1 Paul P Komkoff Jr 2007-08-09 13:18:30 UTC
What app you're trying to build?
Does build succeed if you install libnetfilter_queue-devel ?

Comment 2 Benjamin S. Scarlet 2007-08-11 07:41:30 UTC
libnetfilter_queue-devel is installed. How is that relevant? It only contains
the headers and some links which aren't used by nm.

I'm trying to build my own code, but as nm shows no symbols, that doesn't seem
relevant to me. Compilation succeeds, linking fails. The linker successfully
resolves -lnetfilter_queue, finding the library, but still fails to resolve
calls in my code, giving undefined references to nfq_open & nfq_close (the only
functions called in the code). When I check find out why with nm, I find that nm
can't find any symbols in the libraries either, as shown above. If nm can't find
the symbols, then ld can't be expected to either, so we can drop any worries
about my code.

Comment 3 Benjamin S. Scarlet 2007-08-12 02:14:59 UTC
I stand corrected. My code had the wrong linkage. I'm building in C++ and I
needed extern "C" ... I'm still curious why nm has trouble reading the library,
but the library works.

Comment 4 Paul P Komkoff Jr 2008-02-24 16:56:44 UTC
The correct way list symbols for a dynamic shared object is nm -D filename.

Note You need to log in before you can comment on or make changes to this bug.