Error compiling on Debian 9

Question

Error compiling on Debian 9

Opened this issue 6 years ago · 14 comments

Hi,

I'm getting the following error while compiling:

/tmp/ccO0xafa.o: In function ecurl_mime_init(void*)': main.cpp:(.text+0xc1f): undefined reference to curl_mime_init'
/tmp/ccO0xafa.o: In function ecurl_mime_addpart(curl_mime_s*)': main.cpp:(.text+0xd04): undefined reference to curl_mime_addpart'
/tmp/ccO0xafa.o: In function ecurl_mime_data(curl_mimepart_s*, char const*, unsigned long)': main.cpp:(.text+0xeec): undefined reference to curl_mime_data'
/tmp/ccO0xafa.o: In function ecurl_mime_name(curl_mimepart_s*, char const*)': main.cpp:(.text+0x100c): undefined reference to curl_mime_name'
/tmp/ccO0xafa.o: In function ecurl_mime_filename(curl_mimepart_s*, char const*)': main.cpp:(.text+0x112c): undefined reference to curl_mime_filename'
/tmp/ccO0xafa.o: In function Downloadcacapi::upload_multi[abi:cxx11](std::vector<Downloadcacapi::Upload_multi_arg, std::allocator<Downloadcacapi::Upload_multi_arg> >)': main.cpp:(.text+0x3601): undefined reference to curl_mime_free'
/tmp/ccO0xafa.o: In function Downloadcacapi::upload(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': main.cpp:(.text+0x3eee): undefined reference to curl_mime_free'
collect2: error: ld returned 1 exit status

Answer 1 · 2018-12-06T18:21:18.000Z

my best guess is that you did not add "-lcurl" as an argument to g++,

what is the full command line you executed when you got that error?

Answer 2 · 2018-12-06T18:31:55.000Z

I used g++ src/main.cpp -std=c++17 -lcurl -lpthread -O2 and also tried with "c++16"

Answer 3 · 2018-12-06T18:38:50.000Z

what do you get if you run

g++ -v src/main.cpp -std=c++17 -lcurl -lpthread -O2 2>&1 | pastebinit

?

Answer 4 · 2018-12-06T18:40:47.000Z

http://paste.debian.net/1054673/

Answer 5 · 2018-12-06T18:53:36.000Z

ok, i think i know the problem.

your libcurl headers (curl.h & co) are version >= 7.56.0,
but the actual runtime library you link against (libcurl.so) is much older, older than version 7.56.0.

somehow you got 2 different versions of libcurl installed at the same time, and they are colliding.

what do you get if you run

find / -iname "*curl*.so" 2>/dev/null

? (ps, the command may take several minutes to complete)

Answer 6 · 2018-12-06T18:58:06.000Z

/root/curl/curl-7.62.0/lib/.libs/libcurl.so
/usr/lib/x86_64-linux-gnu/libcurl.so
/usr/local/lib/libcurl.so

Answer 7 · 2018-12-06T19:02:16.000Z

what do you get if you run

g++ -v src/main.cpp -std=c++17 -l/root/curl/curl-7.62.0/lib/.libs/libcurl.so -lpthread -O2 2>&1 | pastebinit

?

Answer 8 · 2018-12-06T19:05:16.000Z

http://paste.debian.net/1054678/

Answer 9 · 2018-12-06T19:24:10.000Z

how about

g++ -v src/main.cpp -std=c++17 -L /root/curl/curl-7.62.0/lib/.libs/ -lcurl -lpthread -O2 2>&1 | pastebinit

?

Answer 10 · 2018-12-06T19:27:54.000Z

http://paste.debian.net/1054681/

Answer 11 · 2018-12-06T19:30:33.000Z

ok, how about

g++ src/main.cpp -std=c++17 -L /root/curl/curl-7.62.0/lib/.libs/ -lcurl -lpthread -O2

?

Answer 12 · 2018-12-07T08:28:25.000Z

That worked thanks!

One last question. What count number should I need to use in order for 987 GB of storage? Because the one I used just creates 6 GB for some reason.

Edit: Now I'm getting the following error:

root@vm2953:/cacdrive# sudo ./a.out config.conf
./a.out(+0xea75)[0x560231ccca75]
./a.out(+0x4b7c)[0x560231cc2b7c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f28a52f2b97]
./a.out(+0x4dba)[0x560231cc2dba]
./a.out:src/main.cpp:1511: unable to open nbd path: /dev/nbd1
: No such file or directory
shutting down, cleaning up.. thread doing the cleanup: 139812563625856
root@vm2953:/cacdrive# sudo modprobe nbd
root@vm2953:~/cacdrive# sudo ./a.out config.conf
starting 3 worker thread(s)... done.
pausing mainthread..
nbdthread waiting for all workers (0/3) to be become ready. (this usually takes a long time - some problem @CAC login system)
worker #2 ready.
worker #1 ready.
upload queue emptied.
worker #3 ready.
all workers (3/3) ready, nbdthread starting NBD_DO_IT.
./a.out(+0xf074)[0x55b1369a1074]
./a.out(+0x12f8d)[0x55b1369a4f8d]
./a.out(+0x14612)[0x55b1369a6612]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7f601586d6db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f6014ff588f]
./a.out:src/main.cpp:2509: failed to seek to -2121531792 in sector file sectorindex.sec: Unknown error -1
shutting down, cleaning up.. thread doing the cleanup: 140050523387648
request socket shutting down, worker exiting.
./a.out(+0x5505)[0x55b136997505]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f6015878890]
/lib/x86_64-linux-gnu/libpthread.so.0(__pthread_rwlock_rdlock+0x12)[0x7f60158722c2]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(CRYPTO_THREAD_read_lock+0x9)[0x7f601412f8a9]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x1387c0)[0x7f60140be7c0]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(ERR_lib_error_string+0x4e)[0x7f60140bebae]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(ERR_error_string_n+0x66)[0x7f60140bed96]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x5cf83)[0x7f6015ae1f83]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x602ef)[0x7f6015ae52ef]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x6113a)[0x7f6015ae613a]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x12f62)[0x7f6015a97f62]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x1f886)[0x7f6015aa4886]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(+0x35456)[0x7f6015aba456]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(curl_multi_perform+0xb4)[0x7f6015abb3f4]
/usr/lib/x86_64-linux-gnu/libcurl.so.4(curl_easy_perform+0xf4)[0x7f6015ab1274]
./a.out(+0xa28f)[0x55b13699c28f]
./a.out(+0xaf33)[0x55b13699cf33]
./a.out(+0xcd0d)[0x55b13699ed0d]
./a.out(+0xce1d)[0x55b13699ee1d]
./a.out(+0x147d9)[0x55b1369a67d9]
./a.out:src/main.cpp:1891: received shutdown signal 11 (Segmentation fault) from PID 24 / UID 0. shutting down..
: Operation now in progress

http://paste.ubuntu.com/p/Mr8Mz45d6x/

Answer 13 · 2018-12-07T14:11:24.000Z

That worked thanks!

nice. the issue was that you have multiple versions of libcurl, and g++ tried to link to
/usr/lib/x86_64-linux-gnu/libcurl.so or /usr/local/lib/libcurl.so when it should have linked to your /root/curl/curl-7.62.0/lib/.libs/libcurl.so library. (and they're incompatible different versions of libcurl.)

Edit: Now I'm getting the following error:

dang, that's an actual bug, can you create a new issue ( https://github.com/divinity76/cacdrive/issues/new ) with that log? (cacdrive somehow thought position "-2121531792" was a valid offset in the sector index file!)

What count number should I need to use in order for 987 GB of storage? Because the one I used just creates 6 GB for some reason.

if we say that 987 GB is 987,000,000,000 bytes, and each count is 4096 bytes, 987000000000/4096 = 240966796.875,

maybe try

dd status=progress if=/dev/zero of=sectorindex.sec bs=25 count=240966796

and warning, the sectorindex file itself will consume 6GB (but cacdrive will be 987GB), it will also take a long time to create the sectorindex file. maybe you could use a sparse file instead (dangerous if your main harddrive goes out of space, but the sectorindex file will be created in a second or 2), eg:

dd if=/dev/zero of=sectorindex.sec bs=1 count=0 seek=6024169900

(again, this method is dangerous if you run out of space on your main harddrive, but the sector index file will be created in a second using this method.)

Answer 14 · 2018-12-09T05:48:23.000Z

Thanks for the detailed explanation of everything.

dang, that's an actual bug, can you create a new issue ( https://github.com/divinity76/cacdrive/issues/new ) with that log? (cacdrive somehow thought position "-2121531792" was a valid offset in the sector index file!)

Unfortunately, the hard drive of my dedicated server failed and it was in RAID 0 setup. I was running proxmox on it and miraculously I was able to recover most of the VMs as I had backups offsite. I'll try to replicate this issue on the same server and if I come across the same error again, I'll do what you said and submit a new issue with the logs.

Edit: So, I was able to replicate that bug and I've created a new issue for that with the logs.