0

I am trying to build SimGear from the FlightGear project using the download_an_compile.sh script (which uses CMake to build the binaries). The build went fine so far, but when the script tried linking the built object file together to a library, I get tons of

//usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2: warning: undefined reference to [email protected]_2

(where ... is a different function name for each message). Now I thought I would just manually instruct CMake to link the lber library to the library being built, by adding -DCMAKE_CXX_STANDARD_LIBRARIES="-llber-2.4" to CMake's arguments. That resulted in

/usr/bin/ld: -llber-2.4 could not be found

Which is a riddle to me, because it is there:

$ ls /usr/lib/x86_64-linux-gnu | grep lber
liblber-2.4.so.2
liblber-2.4.so.2.10.8

In fact, I should not be getting the undefined reference errors, because these functions are all there:

$ nm /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 

$ nm -D /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 | grep ber
0000000000005fe0 T ber_alloc
0000000000005fa0 T ber_alloc_t
0000000000006d50 T ber_bprint
0000000000007ec0 T ber_bvarray_add
0000000000007df0 T ber_bvarray_add_x
0000000000007cd0 T ber_bvarray_dup_x
0000000000007cc0 T ber_bvarray_free
0000000000007c30 T ber_bvarray_free_x
0000000000007830 T ber_bvdup
0000000000007700 T ber_bvecadd
0000000000007650 T ber_bvecadd_x
0000000000007640 T ber_bvecfree
00000000000075c0 T ber_bvecfree_x
00000000000075b0 T ber_bvfree
0000000000007570 T ber_bvfree_x
0000000000007c20 T ber_bvreplace
0000000000007b80 T ber_bvreplace_x
0000000000002c70 T ber_decode_oid
0000000000006fc0 T ber_dump
0000000000006000 T ber_dup
0000000000007820 T ber_dupbv
0000000000007710 T ber_dupbv_x
0000000000004cc0 T ber_encode_oid
0000000000006ab0 T ber_errno_addr
0000000000006a30 T ber_error_print
0000000000003a80 T ber_first_element
0000000000006250 T ber_flatten
0000000000006170 T ber_flatten2
0000000000005f90 T ber_flush
0000000000005db0 T ber_flush2
0000000000005d70 T ber_free
0000000000005d10 T ber_free_buf
00000000000038d0 T ber_get_bitstringa
0000000000003a70 T ber_get_boolean
0000000000003150 T ber_get_enum
0000000000003080 T ber_get_int
0000000000006400 T ber_get_next
0000000000003a20 T ber_get_null
0000000000007ed0 T ber_get_option
0000000000003730 T ber_get_stringa
0000000000003810 T ber_get_stringal
00000000000037a0 T ber_get_stringa_null
0000000000003160 T ber_get_stringb
00000000000031f0 T ber_get_stringbv
0000000000003650 T ber_get_stringbv_null
0000000000002e30 T ber_get_tag
0000000000006380 T ber_init
00000000000060c0 T ber_init2
0000000000006160 T ber_init_w_nullc
000000000020d168 B ber_int_errno_fn
000000000020d178 B ber_int_log_proc
000000000020d190 B ber_int_memory_fns
000000000020d1a0 B ber_int_options
0000000000009590 T ber_int_sb_close
0000000000009610 T ber_int_sb_destroy
0000000000009500 T ber_int_sb_init
0000000000009710 T ber_int_sb_read
00000000000099e0 T ber_int_sb_write
00000000000069d0 T ber_len
0000000000006f70 T ber_log_bprint
00000000000070b0 T ber_log_dump
0000000000007120 T ber_log_sos_dump
0000000000007a50 T ber_mem2bv
0000000000007950 T ber_mem2bv_x
0000000000007460 T ber_memalloc
0000000000007400 T ber_memalloc_x
00000000000074d0 T ber_memcalloc
0000000000007470 T ber_memcalloc_x
0000000000007390 T ber_memfree
0000000000007330 T ber_memfree_x
0000000000007560 T ber_memrealloc
00000000000074e0 T ber_memrealloc_x
00000000000073f0 T ber_memvfree
00000000000073a0 T ber_memvfree_x
0000000000003b00 T ber_next_element
0000000000002e80 T ber_peek_element
0000000000002fd0 T ber_peek_tag
0000000000005370 T ber_printf
00000000000069e0 T ber_ptrlen
0000000000005080 T ber_put_berval
0000000000005100 T ber_put_bitstring
0000000000005290 T ber_put_boolean
0000000000004f30 T ber_put_enum
0000000000004f50 T ber_put_int
0000000000005220 T ber_put_null
0000000000004f70 T ber_put_ostring
0000000000005350 T ber_put_seq
0000000000005360 T ber_put_set
00000000000050b0 T ber_put_string
000000000020d170 B ber_pvt_err_file
0000000000006ad0 T ber_pvt_log_output
000000000020d008 D ber_pvt_log_print
0000000000006c20 T ber_pvt_log_printf
000000000020d1e0 B ber_pvt_opt_on
0000000000008f00 T ber_pvt_sb_buf_destroy
0000000000008ee0 T ber_pvt_sb_buf_init
0000000000009180 T ber_pvt_sb_copy_out
00000000000093b0 T ber_pvt_sb_do_write
0000000000008fe0 T ber_pvt_sb_grow_buffer
00000000000094c0 T ber_pvt_socket_set_nonblock
0000000000005a20 T ber_read
0000000000005ad0 T ber_realloc
0000000000006a20 T ber_remaining
00000000000062f0 T ber_reset
00000000000069f0 T ber_rewind
0000000000003ba0 T ber_scanf
00000000000080f0 T ber_set_option
00000000000059a0 T ber_skip_data
0000000000002f90 T ber_skip_element
0000000000003020 T ber_skip_tag
0000000000008d30 T ber_sockbuf_add_io
0000000000009560 T ber_sockbuf_alloc
0000000000009800 T ber_sockbuf_ctrl
00000000000096a0 T ber_sockbuf_free
000000000020d060 D ber_sockbuf_io_debug
000000000020d0a0 D ber_sockbuf_io_fd
000000000020d0e0 D ber_sockbuf_io_readahead
000000000020d120 D ber_sockbuf_io_tcp
000000000020d020 D ber_sockbuf_io_udp
0000000000008e20 T ber_sockbuf_remove_io
0000000000007130 T ber_sos_dump
00000000000069c0 T ber_start
0000000000005310 T ber_start_seq
0000000000005330 T ber_start_set
0000000000007940 T ber_str2bv
0000000000007840 T ber_str2bv_x
0000000000007ac0 T ber_strdup
0000000000007a60 T ber_strdup_x
0000000000007b70 T ber_strndup
0000000000007b10 T ber_strndup_x
0000000000007ad0 T ber_strnlen
0000000000005c00 T ber_write

ldd also shows that libldap is referencing the right liblber:

$ ldd /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 | grep lber
    liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f28c8bdc000)

Does anyone have any ideas ? I don't … If I forgot any details, please just let me know, and I'll add them !

5
  • So it looks like you have the actual library, but you don't have the symbolic link to liblber.so that ld expects - on Ubuntu by the libldap2-dev package for example May 28, 2021 at 16:46
  • @steeldriver I will try that right away !
    – TheEagle
    May 28, 2021 at 16:55
  • @steeldriver thanks, that did the trick
    – TheEagle
    May 28, 2021 at 18:09
  • @steeldriver if you make it an answer, I'll be happy to accept it !
    – TheEagle
    May 28, 2021 at 18:59
  • Thanks - I have added an answer with some background and references May 28, 2021 at 19:57

1 Answer 1

1

At least in Debian (and derivatives thereof), a shared library's development files are split off into a separate binary package:

If there are development files associated with a shared library, the source package needs to generate a binary development package named libraryname-dev, or if you need to support multiple development versions at a time, librarynameapiversion-dev. Installing the development package must result in installation of all the development files necessary for compiling programs against that shared library.

"Development files" in this context mostly means C/C++ header files, but importantly often includes a symbolic link to the shared library itself

The development package should contain a symlink for the associated shared library without a version number. For example, the libgdbm-dev package should include a symlink from /usr/lib/libgdbm.so to libgdbm.so.3.0.0. This symlink is needed by the linker (ld) when compiling packages, as it will only look for libgdbm.so when compiling dynamically.

In this case, although you already have the shared libraries

liblber-2.4.so.2
liblber-2.4.so.2.10.8

in /usr/lib/x86_64-linux-gnu but do not appear to have the symbolic link /usr/lib/x86_64-linux-gnu/liblber.so, which is provided by the corresponding development package libldap2-dev.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .