Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#62644 closed defect (fixed)

mediainfolib @21.03: error: unknown type name 'sha1_ctx'

Reported by: cooljeanius (Eric Gallager) Owned by: ctreleaven (Craig Treleaven)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ctreleaven (Craig Treleaven)
Port: mediainfolib

Description

I am on Big Sur using Xcode 12.4, and upgrading mediainfolib currently fails for me with some undeclared identifiers errors:

../../../Source/MediaInfo/HashWrapper.cpp:82:25: error: unknown type name 'sha1_ctx'
            m[SHA1]=new sha1_ctx;
                        ^
../../../Source/MediaInfo/HashWrapper.cpp:83:25: error: use of undeclared identifier 'sha1_ctx'
            sha1_begin((sha1_ctx*)m[SHA1]);
                        ^
../../../Source/MediaInfo/HashWrapper.cpp:83:34: error: expected expression
            sha1_begin((sha1_ctx*)m[SHA1]);
                                 ^
../../../Source/MediaInfo/HashWrapper.cpp:90:27: error: unknown type name 'sha224_ctx'
            m[SHA224]=new sha224_ctx;
                          ^
../../../Source/MediaInfo/HashWrapper.cpp:91:27: error: use of undeclared identifier 'sha224_ctx'
            sha224_begin((sha224_ctx*)m[SHA224]);
                          ^
../../../Source/MediaInfo/HashWrapper.cpp:91:38: error: expected expression
            sha224_begin((sha224_ctx*)m[SHA224]);
                                     ^
../../../Source/MediaInfo/HashWrapper.cpp:95:27: error: unknown type name 'sha256_ctx'
            m[SHA256]=new sha256_ctx;
        delete (sha224_ctx*)m[SHA224];
                ^
../../../Source/MediaInfo/HashWrapper.cpp:122:28: error: expected expression
        delete (sha224_ctx*)m[SHA224];
                           ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[1]: *** [../../../Source/MediaInfo/HashWrapper.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
../../../Source/MediaInfo/File__Analyze_Streams.cpp:174:20: warning: 'extern' variable has an initializer [-Wextern-initializer]
extern const char* DolbyVision_Compatibility[DolbyVision_Compatibility_Size] =
                   ^
../../../Source/MediaInfo/File__Analyze_Streams.cpp:1433:23: warning: result of comparison of constant 8 with expression of type 'MediaInfoLib::stream_t' is always true [-Wtautological-constant-out-of-range-compare]
        if (StreamKind<sizeof(Fill_Temp)/sizeof(vector<fill_temp_item>))
            ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.

Attaching full log next.

Attachments (1)

mediainfolibmain.log (127.2 KB) - added by cooljeanius (Eric Gallager) 4 years ago.
main.log for mediainfolib

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by cooljeanius (Eric Gallager)

Attachment: mediainfolibmain.log added

main.log for mediainfolib

comment:1 Changed 4 years ago by mf2k (Frank Schima)

Cc: ctreleaven removed
Owner: set to ctreleaven
Status: newassigned

comment:2 Changed 4 years ago by ctreleaven (Craig Treleaven)

Cc: ctreleaven added

Interesting. Upstream make binaries available and they have a universal x86_64/arm64 build for macOS 11. I presume they must be building that on an M1 Mac?

Also, the previous version built OK on Big Sur x86_64.

Could you try building in trace mode to see if something is overriding their include?

comment:3 in reply to:  2 Changed 4 years ago by cooljeanius (Eric Gallager)

Replying to ctreleaven:

Interesting. Upstream make binaries available and they have a universal x86_64/arm64 build for macOS 11. I presume they must be building that on an M1 Mac?

Also, the previous version built OK on Big Sur x86_64.

Could you try building in trace mode to see if something is overriding their include?

Trace mode reports the following files as hidden after configuring:

Warning: The following existing files were hidden from the build system by trace mode:
  /opt/local/bin/ar
  /opt/local/bin/gawk
  /opt/local/bin/ggrep
  /opt/local/bin/gmkdir
  /opt/local/bin/gsed
  /opt/local/bin/lipo
  /opt/local/bin/mawk
  /opt/local/bin/nawk
  /opt/local/bin/nm
  /opt/local/bin/nmedit
  /opt/local/bin/otool
  /opt/local/bin/ranlib
  /opt/local/bin/strip
  /private/var/select/sh

So, basically, cctools, coreutils, and the various awks. No headers mentioned, though. After running the build phase, it succeeds, and reports headers hidden at this step:

Warning: The following existing files were hidden from the build system by trace mode:
  /opt/local/include/md5.h
  /opt/local/include/sha1.h
  /opt/local/include/sha2.h
  /private/var/select/sh

Running port provides on each of them says they come from libmd:

$ port provides /opt/local/include/md5.h
/opt/local/include/md5.h is provided by: libmd
$ port provides /opt/local/include/sha1.h
/opt/local/include/sha1.h is provided by: libmd
$ port provides /opt/local/include/sha2.h
/opt/local/include/sha2.h is provided by: libmd

So, I guess a conflicts_build for libmd is needed?

comment:4 Changed 4 years ago by ctreleaven (Craig Treleaven)

Another possibility is to add the following to the Portfile:

# make pkg-config act like on Linux, no '-I/opt/local/include' in cflags
configure.env-append    PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include

This might prevent the offending include files from being Included too early.

Would you mind trying this change and reporting back?

comment:5 Changed 4 years ago by kencu (Ken)

perhaps libmd should tuck it's headers away into ${prefix}/include/libmd?

comment:6 Changed 4 years ago by kencu (Ken)

I notice libmd has only one dependent port, so it's not like there is a lot of fixing to do.

comment:7 Changed 4 years ago by ctreleaven (Craig Treleaven)

In 7a229626578119f64974bbe21e48c1466a19e757/macports-ports (master):

mediainfolib: fix conflict with libmd

change configure.cppflags so libmd headers not found before those of the project

See: #62644

comment:8 Changed 4 years ago by ctreleaven (Craig Treleaven)

Resolution: fixed
Status: assignedclosed

Please reopen if not fixed.

comment:9 in reply to:  5 ; Changed 3 years ago by cooljeanius (Eric Gallager)

Replying to kencu:

perhaps libmd should tuck it's headers away into ${prefix}/include/libmd?

That would also help for bug #62643, so, yeah, that sounds like a good idea!

comment:10 in reply to:  9 Changed 3 years ago by cooljeanius (Eric Gallager)

Replying to cooljeanius:

Replying to kencu:

perhaps libmd should tuck it's headers away into ${prefix}/include/libmd?

That would also help for bug #62643, so, yeah, that sounds like a good idea!

This also seems to affect clisp...

Note: See TracTickets for help on using tickets.