Bug 251486
| Summary: | Malformed libraries | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Benjamin S. Scarlet <scarlet> |
| Component: | libnetfilter_queue | Assignee: | Paul P Komkoff Jr <i> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7 | CC: | i |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-02-24 16:56:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
What app you're trying to build? Does build succeed if you install libnetfilter_queue-devel ? 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. 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. The correct way list symbols for a dynamic shared object is nm -D filename. |
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): libnetfilter_queue-0.0.13-3.fc7.x86_64.rpm 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.