Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#61004 closed defect (fixed)

py38-sip +universal: fatal error: 'stdio.h' file not found

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: py-sip

Description

Building py38-sip with the +universal variant fails because it uses an invalid -isysroot:

:info:configure MacOS/X universal binaries will be created using
:info:configure /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/.
:info:build /usr/bin/clang -c -arch x86_64 -arch i386 -arch x86_64 -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -Os -Wall -W -DNDEBUG -I. -o main.o main.c
:info:build main.c:20:10: fatal error: 'stdio.h' file not found
:info:build #include <stdio.h>
:info:build          ^~~~~~~~~
:info:build 1 error generated.

Attachments (1)

main.log (16.9 KB) - added by ryandesign (Ryan Carsten Schmidt) 4 years ago.

Download all attachments as: .zip

Change History (12)

Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: main.log added

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

we were just waiting for this to happen -- base has a nasty habit of leaving configure.sdkroot empty.

<https://github.com/macports/macports-ports/commit/edcd25c14ead450a9e636bb136048f8bc2934b76#diff-5deb2be1b6e1dada51e71b2fde701626>

Last edited 4 years ago by kencu (Ken) (previous) (diff)

comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

It works fine when the universal variant is not used, so I assume py-sip is doing something weird, and that this is not related to what you're talking about in MacPorts base.

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

I suspect it is:

--arch=i386 --sdk= LFLAGS="-F/opt/local/Library/Frameworks 
Last edited 4 years ago by kencu (Ken) (previous) (diff)

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

I will try it with the fix and see if it works.

Last edited 4 years ago by kencu (Ken) (previous) (diff)

comment:5 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

My point is that --sdk= works fine for the non-universal build.

https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/89583/steps/install-port/logs/stdio

And the non-universal build does not say:

MacOS/X universal binaries will be created using

That's something specific to sip.

https://www.riverbankcomputing.com/hg/sip/file/tip/configure.py.in

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

base leaves configure.sdkroot empty when it should be "/". Most ports therefore test for this and set it to "/" if it's empty.

if --sdk is empty then sip goes down it's own pathways for finding sdks, some of which are different when building universal, and fails.

Too tired tonight; will build it tomorrow to confirm.

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

add this:

    # work around base bug
    if {${configure.sdkroot} eq ""} {
        set configure.sdkroot "/"
    }

port builds:

$ port -v installed py38-sip
The following ports are currently installed:
  py38-sip @4.19.24_0+universal (active) platform='darwin 17' archs='i386 x86_64' date='2020-08-17T09:16:56-0700'

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

<https://github.com/macports/macports-ports/pull/8136>

Now -- if you also want to go down the rabbit hole of working with py-sip to fix their own version of their SDK-finding code, feel free. MacPorts has been using it's own for years, however, and even if they do fix theirs, we'll not use it (or at least IMHO we shouldn't start using it just to try to prove to me that we could).

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

Resolution: fixed
Status: assignedclosed

In 1d2ab119635c410e1415a6061e1dea5c6f4dee14/macports-ports (master):

py-sip: work around base bug

configure.sdkroot should never be ""
closes: #61004
see: https://github.com/macports/macports-base/pull/183

comment:10 Changed 4 years ago by michaelld (Michael Dickens)

Merged; thx! I think this would be much better fixed in base (or some other common location, not individual Portfile's) ... and then we could remove these SDK tweaks from all of the Portfile's that do it ... there has got to be a better way!

comment:11 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

We've been using these workarounds in ports for awhile and I don't remember why. I agree it would be better to fix it centrally, but I assume there was a reason why we didn't do that (did it break something else?)

Note: See TracTickets for help on using tickets.