Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#69173 closed defect (invalid)

port fails to upgrade itself

Reported by: mouse07410 (Mouse) Owned by: mouse07410 (Mouse)
Priority: Normal Milestone:
Component: base Version: 2.9.0
Keywords: Cc:
Port:

Description

MacOS Sonoma 14.3, Xcode-15.2, working MacPorts installation under 2.8.1.

As usually, port gets weird ideas about SDK:

$ sudo port -v selfupdate
--->  Updating MacPorts base sources using rsync

Willkommen auf dem RSYNC-server auf ftp.fau.de.
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de.
Not all of our mirrors are available through rsync.


receiving file list ... done
./

sent 66 bytes  received 98 bytes  109.33 bytes/sec
total size is 114413568  speedup is 697643.71
MacPorts base version 2.8.1 installed,
MacPorts base version 2.9.0 downloaded.
--->  Updating the ports tree
Synchronizing local ports tree from rsync://rsync.macports.org/macports/release/tarballs/ports.tar

Willkommen auf dem RSYNC-server auf ftp.fau.de.
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de.
Not all of our mirrors are available through rsync.


receiving file list ... done
./

sent 68 bytes  received 99 bytes  111.33 bytes/sec
total size is 125065216  speedup is 748893.51

Willkommen auf dem RSYNC-server auf ftp.fau.de.
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de.
Not all of our mirrors are available through rsync.


receiving file list ... done
./

sent 68 bytes  received 99 bytes  111.33 bytes/sec
total size is 23532157  speedup is 140911.12
--->  MacPorts base is outdated, installing new version 2.9.0
Installing new MacPorts release in /opt/local as root:admin; permissions 0755

checking build system type... x86_64-apple-darwin23.3.0
checking host system type... x86_64-apple-darwin23.3.0
checking target system type... x86_64-apple-darwin23.3.0
checking MacPorts version... 2.9.0
checking for sw_vers... /usr/bin/sw_vers
checking for defaults... /usr/bin/defaults
checking for xcode-select... /usr/bin/xcode-select
checking macOS version... 14.3
checking Xcode location... /Applications/Xcode.app/Contents/Developer
checking Xcode version... 15.2
checking whether the C compiler works... no
configure: error: in `/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base':
configure: error: C compiler cannot create executables
See `config.log' for more details
Command failed: CC=/usr/bin/cc SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk ./configure --prefix=/opt/local --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline && SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk make -j20 SELFUPDATING=1 && make install SELFUPDATING=1
Exit code: 77
Error: Error installing new MacPorts base: command execution failed
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: command execution failed
$ ll /Library/Developer/CommandLineTools/SDKs/
total 0
drwxr-xr-x  4 root  admin  128 Jan 22 16:26 ./
drwxr-xr-x  4 root  admin  128 Jan 28  2023 ../
drwxr-xr-x  3 root  admin   96 Jan 28  2023 MacOSX.sdk/
lrwxr-xr-x  1 root  admin   10 Jan 22 16:26 MacOSX14.sdk@ -> MacOSX.sdk

I don't need to state that C compiler works:

$ pwd
/Users/ur20980/src
$ cat t1b.c
#include <stdio.h>

int main(void) {
  printf("Hello\n");
  return 0;
}
$ cc -o t1b t1b.c
$ ./t1b
Hello
$ 

Change History (12)

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

please post error from config.log

See `config.log' for more details

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

Component: portsbase
Port: Macports itself removed

What do you mean by "port gets weird ideas about SDK"? It looks like it's trying to use the macOS 14 SDK, and it looks like you're on macOS 14, so that should be ok.

Last edited 4 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:3 Changed 4 months ago by mouse07410 (Mouse)

I mean - it fails to deal correctly with the obviously-present and obviously working SDK (whose version is right for this version of OS).

Sorry, I don't have that config.log anymore - because my next step was downloading MacPorts-2.9.0 binary installer and install it on top of the 2.8.1. Which alleviated the problem.

But here's an interesting example:

$ SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk clang -g -fsanitize=address,undefined -fno-omit-frame-pointer -I/opt/local/include -o t1 t1.c -L/opt/local/lib -lcrypto
clang: error: Failed to open property list '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/SDKSettings.plist'
t1.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
         ^~~~~~~~~
1 error generated.
$ echo $CFLAGS
-O3 -std=gnu18 -march=native -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
$ clang ${CFLAGS} -g -fsanitize=address,undefined -fno-omit-frame-pointer -I/opt/local/include -o t1 t1.c -L/opt/local/lib -lcrypto
t1.c:122:13: warning: 'ENGINE_load_private_key' is deprecated [-Wdeprecated-declarations]
  privkey = ENGINE_load_private_key(e, SignPrivKey, NULL, &cb_data);
            ^
/opt/local/include/openssl/engine.h:637:1: note: 'ENGINE_load_private_key' has been explicitly marked deprecated here
OSSL_DEPRECATEDIN_3_0
^
/opt/local/include/openssl/macros.h:194:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
#   define OSSL_DEPRECATEDIN_3_0                OSSL_DEPRECATED(3.0)
                                                ^
.  .  .
                                                ^
/opt/local/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
#     define OSSL_DEPRECATED(since) __attribute__((deprecated))
                                                   ^
6 warnings generated.
$ ./t1
t1(89852,0x7ff85c9367c0) malloc: nano zone abandoned due to inability to reserve vm space.
Using YubiHSM device...
Signature padding is RSA-PSS padding
Enter PKCS#11 token PIN for YubiHSM:
Set RSA signature padding to RSA-PSS padding
Signed (data len=83, sig len=384):
23 c5 ae 7d bd 5c c7 86 0c 22 45 d7 5f 00 66 84 
8b 9d 75 ef 2b 3b 61 87 f2 3b ea a1 8d a0 1b 87 
.  .  .
38 76 2d ac d3 2a 86 8d 44 73 40 4c 36 20 99 77 

$ 
$ SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk clang -g -fsanitize=address,undefined -fno-omit-frame-pointer -I/opt/local/include -o t1 t1.c -L/opt/local/lib -lcrypto
clang: error: Failed to open property list '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/SDKSettings.plist'
t1.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
         ^~~~~~~~~
1 error generated.
$ ll /Library/Developer/CommandLineTools/SDKs/
total 0
drwxr-xr-x  4 root  admin  128 Jan 22 16:26 ./
drwxr-xr-x  4 root  admin  128 Jan 28  2023 ../
drwxr-xr-x  3 root  admin   96 Jan 28  2023 MacOSX.sdk/
lrwxr-xr-x  1 root  admin   10 Jan 22 16:26 MacOSX14.sdk@ -> MacOSX.sdk
$ 

comment:4 Changed 4 months ago by mouse07410 (Mouse)

In other words, it looks like

  • SDKROOT=...... fails consistently, but
  • -isysroot=....... works fine, and
  • ...../MacOSX.sdk is much preferred to ...../MacOSX14.sdk

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

generally speaking, trying to outsmart xcrun by setting the SDKROOT yourself (as some folks are wont to do in their terminal startup scripts, or manually), or, God forbid, making your own symlinks in the SDK folder between the SDKs to match what you imagine might be a good plan, is going to be a doomed enterprise that will cause nothing but build failures, troubles, and hassles.

comment:6 Changed 4 months ago by mouse07410 (Mouse)

@kencu, it's port itself that's trying to outsmart xcrun (in this ticket's case, during attempt to rebuild itself from source). I merely created a (hopefully, minimal) reproducer of the problem.

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

I don't have an Intel setup currently that matches yours with the latest latest, but on my arm Sonoma system, latest everything, the build is flawless.

You have a pristine system?

comment:8 Changed 4 months ago by ryandesign (Ryan Carsten Schmidt)

If your compiler can't find stdio.h then something is wrong with your system. The fact that you can reproduce it on the command line proves it has nothing to do with MacPorts.

comment:9 Changed 4 months ago by mouse07410 (Mouse)

When SDK path is fed to the compiler via SDKROOT env var - it consistently fails.

When SDK path is fed to the compiler via -isysroot command-line argument - it consistently works.

It looked like Macports did not make the smart choice here.

That's all I have to say on this subject.

comment:10 Changed 4 months ago by mouse07410 (Mouse)

Owner: set to mouse07410
Status: newassigned
Summary: port fails to upgrade to 2.9.0port fails to upgrade itself

Problem discovered: misaligned /Library/Developer/CommandLineTools/SDKs and /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/.

Current Xcode.app is 15.2. Remedied this problem by removing whatever was in /Library/Developer/CommandLineTools/SDKs and installing CLT-15.1 (since there's no CLT-15.2, only 15.1 and 15.3-beta).

Recommendation to other users: since Macports tends to be leery of using /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/, ensure the latest stable CLT is installed - even though it sometimes interferes with Haskell toolchain (less so recently).

comment:11 Changed 4 months ago by kencu (Ken)

Resolution: invalid
Status: assignedclosed

people mess up so often by having different xcode and clt versions installed.

macports should almost refuse to run if it detects this.

comment:12 Changed 4 months ago by mouse07410 (Mouse)

@Ken, I would agree if Macports gave an unambiguous clear error message pointing at the problem.

Note: See TracTickets for help on using tickets.