1.17.1 32-bit compile fails #1008

freakout42 · 2023-10-22T08:50:43Z

[ 97%] Building CXX object libheif/plugins/CMakeFiles/heif-jpegenc.dir/encoder_jpeg.cc.o /home/axel/p/rpm/BUILD/libheif-1.17.1/libheif/plugins/encoder_jpeg.cc: In function 'heif_error jpeg_encode_image(void*, const heif_image*, heif_image_input_class)': /home/axel/p/rpm/BUILD/libheif-1.17.1/libheif/plugins/encoder_jpeg.cc:366:37: error: invalid conversion from 'long unsigned int*' to 'size_t*' {aka 'unsigned int*'} [-fpermissive] 366 | jpeg_mem_dest(&cinfo, &outbuffer, &outlength); | ^~~~~~~~~~ | | | long unsigned int* In file included from /home/axel/p/rpm/BUILD/libheif-1.17.1/libheif/plugins/encoder_jpeg.cc:33: /opt/jpeg/include/jpeglib.h:981:41: note: initializing argument 3 of 'void jpeg_mem_dest(j_compress_ptr, unsigned char**, size_t*)' 981 | size_t * outsize)); | ~~~~~~~~~^~~~~~~ /opt/jpeg/include/jpeglib.h:877:25: note: in definition of macro 'JPP' 877 | #define JPP(arglist) arglist | ^~~~~~~ make[2]: *** [libheif/plugins/CMakeFiles/heif-jpegenc.dir/build.make:76: libheif/plugins/CMakeFiles/heif-jpegenc.dir/encoder_jpeg.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:361: libheif/plugins/CMakeFiles/heif-jpegenc.dir/all] Error 2 make: *** [Makefile:156: all] Error 2

The text was updated successfully, but these errors were encountered:

kmilos · 2023-10-23T14:47:06Z

See also #948 (comment) and 963f7bf

Note also that there were no such warnings building 1.17.1 on e.g. mingw32/clang32...

What system & compiler is this?

kmilos · 2023-10-24T12:49:01Z

There are, however, numerous other warnings when building for 32-bit that could be problematic:

C:/_/B/src/libheif-1.17.1/libheif/bitstream.cc:75:32: warning: implicit conversion loses integer precision: 'int64_t' (aka 'long long') to 'size_t' (aka 'unsigned int') [-Wshorten-64-to-32]
  
     75 |     memcpy(m_owned_data, data, m_length);
  
        |     ~~~~~~                     ^~~~~~~~
  
  1 warning generated.
  
  [32/84] Building CXX object libheif/CMakeFiles/heif.dir/box.cc.obj
  C:/_/B/src/libheif-1.17.1/libheif/box.cc:394:28: warning: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') [-Wshorten-64-to-32]
    394 |     if (range.prepare_read(content_size)) {
        |               ~~~~~~~~~~~~ ^~~~~~~~~~~~
  C:/_/B/src/libheif-1.17.1/libheif/box.cc:639:67: warning: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') [-Wshorten-64-to-32]
    639 |   auto status = range.wait_for_available_bytes(hdr.get_box_size() - hdr.get_header_size());
        |                       ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
  C:/_/B/src/libheif-1.17.1/libheif/box.cc:668:27: warning: implicit conversion loses integer precision: 'int64_t' (aka 'long long') to 'size_t' (aka 'unsigned int') [-Wshorten-64-to-32]
    667 |   BitstreamRange boxrange(range.get_istream(),
        |                  ~~~~~~~~
    668 |                           box_size_without_header,
  
        |                           ^~~~~~~~~~~~~~~~~~~~~~~
  
  3 warnings generated.
  
  [33/84] Building CXX object tests/CMakeFiles/encode.dir/main.cc.obj
  [34/84] Building CXX object libheif/CMakeFiles/heif.dir/error.cc.obj
  [35/84] Building CXX object tests/CMakeFiles/region.dir/main.cc.obj
  [36/84] Building CXX object libheif/CMakeFiles/heif.dir/heif.cc.obj
  C:/_/B/src/libheif-1.17.1/libheif/heif.cc:1636:10: warning: result of comparison of constant 429[496](https://github.com/msys2/MINGW-packages/actions/runs/6626310915/job/17998980714?pr=18951#step:11:497)7295 with expression of type 'uint16_t' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare]
   1636 |       cp > std::numeric_limits<std::underlying_type<heif_color_primaries>::type>::max()) {
        |       ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  C:/_/B/src/libheif-1.17.1/libheif/heif.cc:1677:10: warning: result of comparison of constant 4294967295 with expression of type 'uint16_t' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare]
   1677 |       tc > std::numeric_limits<std::underlying_type<heif_transfer_characteristics>::type>::max()) {
        |       ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  C:/_/B/src/libheif-1.17.1/libheif/heif.cc:1714:10: warning: result of comparison of constant 4294967295 with expression of type 'uint16_t' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare]
  
   1714 |       mc > std::numeric_limits<std::underlying_type<heif_matrix_coefficients>::type>::max()) {
  
        |       ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  3 warnings generated.
  
  [37/84] Building CXX object libheif/CMakeFiles/heif.dir/context.cc.obj
  [38/84] Building CXX object libheif/CMakeFiles/heif.dir/pixelimage.cc.obj
  [39/84] Building CXX object libheif/CMakeFiles/heif.dir/file.cc.obj
  C:/_/B/src/libheif-1.17.1/libheif/file.cc:105:40: warning: implicit conversion loses integer precision: 'uint64_t' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') [-Wshorten-64-to-32]
  
    105 |   BitstreamRange range(m_input_stream, maxSize);
  
        |                  ~~~~~                 ^~~~~~~
  
  1 warning generated.

farindk · 2023-10-24T14:41:47Z

Now, the question is: if we use size_t, we will be limited to 32bit box sizes. That's usually enough, but there could theoretically be boxes with 64bit sizes. My feeling is that those files will not read correctly anyway on 32bit systems because the file handling probably does not work for >4GB files on 32bit systems.

Is there a need to support large HEIF files (>4 GB) on 32bit systems?

kmilos · 2023-10-24T15:45:35Z

Now, the question is: if we use size_t, we will be limited to 32bit box sizes. That's usually enough, but there could theoretically be boxes with 64bit sizes. My feeling is that those files will not read correctly anyway on 32bit systems because the file handling probably does not work for >4GB files on 32bit systems.

That's right. So you'd still need to keep those int64/uint64 internally when parsing and only at the actual file/memory access time dynamically detect >4GB and throw an unsupported error on 32-bit systems. Not sure if it's worth it though knowing they're being slowly phased out...

Anyway, probably a separate issue to the 32-bit libjpeg one the OP reported.

farindk · 2023-10-26T21:25:07Z

Note also that there were no such warnings building 1.17.1 on e.g. mingw32/clang32...

The error message of the OP says:

/opt/jpeg/include/jpeglib.h:981:41: note: initializing argument 3 of 'void jpeg_mem_dest(j_compress_ptr, unsigned char**, size_t*)

Note the size_t for the third argument. For my libjpeg-turbo installation though, the third argument is unsigned long. So there seems to be a type disagreement in different versions of libjpeg.
@freakout42 What libjpeg version do you have installed?

freakout42 · 2024-01-02T11:23:31Z

my jpeg lib is build from jpegsrc.v9e.tar.gz from http://www.ijg.org/files

bradh · 2024-01-02T23:49:13Z

@freakout42 Can you test if it works with a version from https://libjpeg-turbo.org/ ?

freakout42 · 2024-01-03T08:52:35Z

with libjeeg-turbo different error:

/home/axel/p/rpm/BUILD/libheif-1.17.6/examples/encoder_jpeg.cc:83:6: error: 'void jpeg_write_icc_profile(j_compress_ptr, const JOCTET*, unsigned int)' was declared 'extern' and later 'static' [-Werror=permissive]
   83 | void jpeg_write_icc_profile(j_compress_ptr cinfo, const JOCTET* icc_data_ptr,
      |      ^~~~~~~~~~~~~~~~~~~~~~
In file included from /home/axel/p/rpm/BUILD/libheif-1.17.6/examples/encoder_jpeg.h:34,
                 from /home/axel/p/rpm/BUILD/libheif-1.17.6/examples/encoder_jpeg.cc:34:
/opt/jpeg/jpegt/include/jpeglib.h:1043:14: note: previous declaration of 'void jpeg_write_icc_profile(j_compress_ptr, const JOCTET*, unsigned int)'
 1043 | EXTERN(void) jpeg_write_icc_profile(j_compress_ptr cinfo,
      |              ^~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [examples/CMakeFiles/heif-convert.dir/build.make:146: examples/CMakeFiles/heif-convert.dir/encoder_jpeg.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:205: examples/CMakeFiles/heif-convert.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

bradh · 2024-01-03T10:15:02Z

I'm guessing your cmake step did not have HAVE_JPEG_WRITE_ICC_PROFILE=1.

Can you see why that happened in the cmake tests?

freakout42 · 2024-01-03T13:34:45Z

when i do not explicitely set the jpeg-libs and -include paths but let pkgconfig do the job libheif compiles and works perfectly - thanks for your help and for libheif

Fix the following libjpeg build failure raised since version 1.17.0 and strukturag@ebd13a2 because third argument of jpeg_mem_dest is defined as size_t* on libjpeg instead of unsigned long* on jpeg-turbo: /home/buildroot/autobuild/instance-3/output-1/build/libheif-1.17.5/libheif/plugins/encoder_jpeg.cc: In function 'heif_error jpeg_encode_image(void*, const heif_image*, heif_image_input_class)': /home/buildroot/autobuild/instance-3/output-1/build/libheif-1.17.5/libheif/plugins/encoder_jpeg.cc:366:37: error: invalid conversion from 'long unsigned int*' to 'size_t*' {aka 'unsigned int*'} [-fpermissive] 366 | jpeg_mem_dest(&cinfo, &outbuffer, &outlength); | ^~~~~~~~~~ | | | long unsigned int* Fix strukturag#1008 and strukturag#1086 Fixes: - http://autobuild.buildroot.org/results/8ca909564c8dabe28ad08c96ebbc04b25592e727 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

bradh mentioned this issue Jan 2, 2024

32-bit compile fails #1086

Closed

freakout42 closed this as completed Jan 3, 2024

ffontaine mentioned this issue Jan 31, 2024

libheif/plugins/encoder_jpeg.cc: fix libjpeg build #1120

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

1.17.1 32-bit compile fails #1008

1.17.1 32-bit compile fails #1008

freakout42 commented Oct 22, 2023

kmilos commented Oct 23, 2023 •

edited

kmilos commented Oct 24, 2023 •

edited

farindk commented Oct 24, 2023

kmilos commented Oct 24, 2023

farindk commented Oct 26, 2023

freakout42 commented Jan 2, 2024

bradh commented Jan 2, 2024

freakout42 commented Jan 3, 2024

bradh commented Jan 3, 2024

freakout42 commented Jan 3, 2024

1.17.1 32-bit compile fails #1008

1.17.1 32-bit compile fails #1008

Comments

freakout42 commented Oct 22, 2023

kmilos commented Oct 23, 2023 • edited

kmilos commented Oct 24, 2023 • edited

farindk commented Oct 24, 2023

kmilos commented Oct 24, 2023

farindk commented Oct 26, 2023

freakout42 commented Jan 2, 2024

bradh commented Jan 2, 2024

freakout42 commented Jan 3, 2024

bradh commented Jan 3, 2024

freakout42 commented Jan 3, 2024

kmilos commented Oct 23, 2023 •

edited

kmilos commented Oct 24, 2023 •

edited