Build issue, ubuntu 20.04 math linking

[ezelkow1]

Was getting this building for another project and right now just working within ubuntu 20.04, when I went to build the openssl version I was getting:

cc -o t_cose_test main.o test/t_cose_test.o test/run_tests.o test/t_cose_sign_verify_test.o test/t_cose_make_test_messages.o test/t_cose_make_openssl_test_key.o libt_cose.a -lqcbor -l crypto
/usr/bin/ld: /usr/local/lib/libqcbor.a(qcbor_decode.o): in function DoubleConvertAll': qcbor_decode.c:(.text+0x293): undefined reference to exp2'
/usr/bin/ld: qcbor_decode.c:(.text+0x325): undefined reference to pow' /usr/bin/ld: qcbor_decode.c:(.text+0x35f): undefined reference to pow'
/usr/bin/ld: qcbor_decode.c:(.text+0x3be): undefined reference to exp2' /usr/bin/ld: /usr/local/lib/libqcbor.a(qcbor_decode.o): in function ConvertInt64':
qcbor_decode.c:(.text+0x4c5): undefined reference to feclearexcept' /usr/bin/ld: qcbor_decode.c:(.text+0x4d4): undefined reference to llround'
/usr/bin/ld: qcbor_decode.c:(.text+0x4e0): undefined reference to lroundf' /usr/bin/ld: qcbor_decode.c:(.text+0x4ee): undefined reference to fetestexcept'
/usr/bin/ld: /usr/local/lib/libqcbor.a(qcbor_decode.o): in function ConvertUInt64': qcbor_decode.c:(.text+0x582): undefined reference to feclearexcept'
/usr/bin/ld: qcbor_decode.c:(.text+0x5af): undefined reference to round' /usr/bin/ld: qcbor_decode.c:(.text+0x5f9): undefined reference to roundf'
/usr/bin/ld: qcbor_decode.c:(.text+0x639): undefined reference to `fetestexcept'
collect2: error: ld returned 1 exit status

Editing the makefile to add a -lm to the linking steps resolved it though. So wasnt sure if it was missing for a reason?

[laurencelundblade]

Thanks for reporting. It should be added so it works out of the box. I will do that in the next few days.

Floating point is not needed for t_cose to work. It's just that qcbor has some features that need floating-point. t_cose doesn't use those. So another solution here is to recompile QCBOR with floating point turned off.

[laurencelundblade]

Looked into this a bit more and I'm now confused.

There should be no references in t_cose_test main.o, test/run_tests.o and such to QCBOR functions that need the math library so they linker shouldn't go looking for these math functions.

I don't have an ubuntu system, but I do run t_cose CI against ubuntu with OpenSSL in GitHub and it is OK without -lm.

I tried a few things on MacOS to see what symbols showed up. It wasn't conclusive and I didn't get to the bottom of it, but it may relate to use of shared libraries and dynamic linking.

Basically, it seems like the linker should be taking care of this and that -lm should not be necessary. I don't want to add -lm to the makefiles unless I know it really is necessary. It doesn't seem necessary to me yet.

Maybe you can check a few things on your end?

Thx.

[ezelkow1]

Sure, lets leave this open for now. Right now Im just trying to get some things going to support the new CAT spec using t_cose (hopefully end up as an open sourced library for CAT). Once I get further along with that and start integrating it back into the main project it's for (apache traffic server) I can see if there are more build oddities with it there since we run ATS through a ton of various CI builds

[kentakayama]

@ezelkow1 @laurencelundblade

This issue is a bit complicated, but these solutions may help you.

• Solution 1: build only libt_cose.a
  • $ make -f Makefile.ossl libt_cose.a in t_cose dir
• Solution 2: link libm to t_cose_test (and other tests)
  • Edit Makefile to add -lm then $ make -f Makefile.ossl in t_cose dir
• Solution 3: Use cmake to build t_cose
  • $ mkdir build && cd build && cmake .. && make in t_cose dir
  • cmake seems automatically append "-lm" options (see below in detail)
• Solution 4: build QCBOR without depending libm
  • $ make CMD_LINE="-DQCBOR_DISABLE_FLOAT_HW_USE" in QCBOR dir, and then
  • $ make -f Makefile.ossl in t_cose dir

CI output shows that cmake automatically finds libm.
https://github.com/laurencelundblade/t_cose/actions/runs/4549030731/jobs/8020683581#step:11:27

+ mkdir build
+ cd build
+ cmake -DCRYPTO_PROVIDER=OpenSSL ..
-- The C compiler identification is GNU 9.4.0
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- No build type selected, defaulting to Release
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1.1.1f")  
-- Looking for sin in m
-- Looking for sin in m - found
-- Found QCBOR: /usr/local/lib/libqcbor.a  

In my environment the cmake command generates t_cose/build/CMakeFiles/t_cose_test.dir/link.txt like below.

/usr/bin/cc -O3 -DNDEBUG CMakeFiles/t_cose_test.dir/main.c.o CMakeFiles/t_cose_test.dir/test/run_tests.c.o CMakeFiles/t_cose_test.dir/test/t_cose_make_test_messages.c.o CMakeFiles/t_cose_test.dir/test/t_cose_test.c.o CMakeFiles/t_cose_test.dir/test/t_cose_param_test.c.o CMakeFiles/t_cose_test.dir/test/t_cose_sign_verify_test.c.o CMakeFiles/t_cose_test.dir/test/t_cose_compute_validate_mac_test.c.o CMakeFiles/t_cose_test.dir/test/t_cose_make_openssl_test_key.c.o -o t_cose_test libt_cose.a /usr/lib/x86_64-linux-gnu/libcrypto.so /usr/local/lib/libqcbor.a -lm

[laurencelundblade]

Ken has it figured out here. Will fix this in the next few days by adding -lm in the Makefile.