Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#69676 closed defect (fixed)

libdicom @1.1.0_0+universal: error: implicit declaration of function 'close' is invalid in C99

Reported by: conradkun (Conrad Cardona) Owned by: bgilbert (Benjamin Gilbert)
Priority: Normal Milestone:
Component: ports Version: 2.9.3
Keywords: Cc:
Port: libdicom

Description

When trying to install the universal version of libdicom, MacPorts will fail due to what I understand is a compiler error: error: implicit declaration of function 'close' is invalid in C99

Running MacPorts 2.9.3 on macOS Monterey 12.0.1. Same behaviour on Ventura and Sonoma. Attached is the output in main.log.

Attachments (2)

main.log (30.4 KB) - added by conradkun (Conrad Cardona) 7 months ago.
Output generated by MacPorts when trying to install libdicom
meson-log.txt (20.4 KB) - added by conradkun (Conrad Cardona) 7 months ago.
Log of the meson build step

Download all attachments as: .zip

Change History (8)

Changed 7 months ago by conradkun (Conrad Cardona)

Attachment: main.log added

Output generated by MacPorts when trying to install libdicom

comment:1 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Owner: set to bgilbert
Status: newassigned
Summary: libdicom @1.1.0_0+universal: Build breaks due to compiler errorlibdicom @1.1.0_0+universal: error: implicit declaration of function 'close' is invalid in C99

Yes, implicit declaration of functions has been forbidden ever since Xcode 12.

What's curious is that we get a successful build on our buildbot machines on every OS version when not using the universal variant.

The functions it's complaining about—close, read, lseek—are defined in <unistd.h>. The file in question does include <unistd.h> if it detects at configure time that <unistd.h> exists. And therein lies the problem because your log shows:

:info:configure Has header "unistd.h" : NO

We need to see the logs from the configuration system that tell us why it thinks <unistd.h> doesn't exist when it does. This port uses the meson build system so look in the work directory (port work libdicom) for a meson logfile and attach it to this ticket.

Changed 7 months ago by conradkun (Conrad Cardona)

Attachment: meson-log.txt added

Log of the meson build step

comment:2 Changed 7 months ago by conradkun (Conrad Cardona)

I have just attached what I assume will be the most relevant file I could find, the only file in ./build/meson-logs.

I can see a possible culprit:

clang error: cannot use 'cpp-output' output with multiple -arch options

Let me know if I can be of any further help and thank you for quick quick reply!

comment:3 Changed 7 months ago by bgilbert (Benjamin Gilbert)

Thanks for the report! Some Meson checks, including compiler.has_header(), don't work properly with universal builds. As a result, libdicom skips including unistd.h. I've filed a libdicom PR to fail meson setup with a clear error in this case, and will work around it in MacPorts using the muniversal portgroup.

comment:4 Changed 7 months ago by bgilbert (Benjamin Gilbert)

Resolution: fixed
Status: assignedclosed

In 33f8eed6f55e980ef90cb9f02dc64002901e9cdc/macports-ports (master):

libdicom: fix universal build

Certain Meson checks don't work properly for universal builds, causing
libdicom to skip including unistd.h and then fail the build on an implicit
function declaration. Use muniversal to build each arch separately.

Fixes: #69676
See: https://github.com/ImagingDataCommons/libdicom/pull/86

comment:5 Changed 7 months ago by conradkun (Conrad Cardona)

Thank you! is the fix already available, then?

comment:6 Changed 7 months ago by bgilbert (Benjamin Gilbert)

The fix is pushed to the Git repo, but may not have reached all the mirrors yet. If it doesn't work for you after running port selfupdate, try again after a while. I'm not sure how often the mirrors sync, but I'd expect it'd take a day at most.

Note: See TracTickets for help on using tickets.