Undefined symbols when linking executables with libjpeg.a V. 3.0.2 (Linux only)
Fawcett, Simon
Hi,
We have run in to a build problem with 3.0.2 using a build process, and calling code, which worked successfully on 2.0.0, 2.1.3 and 2.1.5, with the same machine and compiler setup.
The libjpeg-turbo Cmake build itself works fine, completes installation and run its own tests.
When I try to use the static archive it produces, libjpeg.a, to link our executable, it fails with undefined symbols:
The undefined symbols produced when using 3.0.2 (first few – there are a lot)
/home/lads/lw/MAINLINE/lads/lib/amd/linux64/gnu/sos_/libidrvjpg.a(jp_drive.o): In function `LiDriverJPGCompress':
jp_drive.cpp:(.text+0x267): undefined reference to `jpeg_start_compress'
jp_drive.cpp:(.text+0x298): undefined reference to `jpeg_write_scanlines'
/home/lads/lw/MAINLINE/lads/lib/amd/linux64/gnu/sos_/libidrvjpg.a(jp_drive.o): In function `LiDriverJPGDecompress':
jp_drive.cpp:(.text+0x4a9): undefined reference to `jpeg_start_decompress'
jp_drive.cpp:(.text+0x514): undefined reference to `jpeg_read_scanlines'
/home/lads/lw/MAINLINE/lads/lib/amd/linux64/gnu/sos_/libidrvjpg.a(jp_input.o): In function `lw_jp_input_data':
jp_input.cpp:(.text+0x338): undefined reference to `jpeg_start_decompress'
jp_input.cpp:(.text+0x3eb): undefined reference to `jpeg_read_scanlines'
/home/lads/lw/MAINLINE/lads/lib/amd/linux64/gnu/sos_/libidrvjpg.a(jp_outpt.o): In function `lw_jp_image_begin':
jp_outpt.cpp:(.text+0x134): undefined reference to `jpeg_start_compress'
/home/lads/lw/MAINLINE/lads/lib/amd/linux64/gnu/sos_/libidrvjpg.a(jp_outpt.o): In function `lw_jp_scan_rgb_nat8':
jp_outpt.cpp:(.text+0x2da): undefined reference to `jpeg_write_scanlines'
The linker also reports undefined refs which are (I presume) "internal" references amongst libjpeg-turbo's own files
/home/lads/lw/MAINLINE/lads/lib/amd/linux64/gnu/sos_/libidrvjpg.a(jcmarker.c.o): In function `emit_dqt':
jcmarker.c:(.text+0x8fa): undefined reference to `jpeg_natural_order'
jcmarker.c:(.text+0x900): undefined reference to `jpeg_natural_order'
/home/lads/lw/MAINLINE/lads/lib/amd/linux64/gnu/sos_/libidrvjpg.a(jdinput.c.o): In function `start_input_pass':
jdinput.c:(.text+0xaf): undefined reference to `jdiv_round_up'
jdinput.c:(.text+0xc7): undefined reference to `jdiv_round_up'
nm regards the symbols as defined in both versions (LJPT215 is 2.1.5 which links fine, LJPT302r is 3.0.2 which doesn't)
nm -A --defined-only LJPT215/EXTN_STAGE/amd/linux64/gnu/sost/lib64/libjpeg.a | grep jpeg_start_compress
LJPT215/EXTN_STAGE/amd/linux64/gnu/sost/lib64/libjpeg.a:jcapistd.c.o:0000000000000000 T jpeg_start_compress
nm -A --defined-only LJPT302r/EXTN_STAGE/amd/linux64/gnu/sost/lib64/libjpeg.a | grep jpeg_start_compress
LJPT302r/EXTN_STAGE/amd/linux64/gnu/sost/lib64/libjpeg.a:jcapistd.c.o:0000000000000000 T jpeg_start_compress
We don’t have this problem with our Windows build (although we did run in to the issue with the MSVC runtime dependency), or (incredibly) our Mac (ARM) build.
I’m baffled – a “second opinion” build technique by one of my colleagues using Docker had the same problem. He then produced 2 more builds trying the -DWITH_JPEG7=1 and -DWITH_JPEG8=1 options but again, no change.
The Cmake command I use is:
cmake -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=~/LJPT302r/EXTN_STAGE/amd/linux64/gnu/sost/lib64 ~/LJPT302r/libjpeg-turbo-3.0.2
Machine config (unchanged since using LJPT 2.0.0 and 2.1.3):
Linux sfi6w033 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
cmake version 3.21.3
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)
BTW in the process of running 2.1.x builds (to check our build process is not broken by a machine set-up change) I tried “2.1.91” and found it failed at an early stage and did not produce a libjpeg.a or run its own tests.
Simon Fawcett
DRC
Weird. I use CentOS 7 with GCC 7-10 for testing, and I have never seen this issue. libjpeg-turbo's own tests include cjpeg-static, djpeg-static, and jpegtran-static, all of which link with libjpeg.a, so there must be something different in how the downstream code is trying to link with libjpeg.a. A minimal reproducible test case would be helpful.
--
You received this message because you are subscribed to the Google Groups "libjpeg-turbo Developer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libjpeg-turbo-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libjpeg-turbo-devel/VI1PR10MB398186F5222E647B6327D25FF1322%40VI1PR10MB3981.EURPRD10.PROD.OUTLOOK.COM.