Opened 5 weeks ago

Last modified 5 weeks ago

#72582 new defect

A MacPort update failed. The installer couldn't identify the correct Xcode path

Reported by: scrutinizer11 Owned by:
Priority: Normal Milestone:
Component: base Version:
Keywords: Cc:
Port:

Description (last modified by ryandesign (Ryan Carsten Schmidt))

Hello,

None of the fixes and workarounds suggested in the relevant section about Xcode helped resolve my issue. The issue originates from the fact that the correct path is "/Applications/Development/Xcode 6.app/.../...", but it aborts generating the log line (the sender is /bin/sh) that tells it was unable to find /Applications/Development Xcode. It looks like it chokes on spaces in pathnames. Setting DEVELOPER_DIR explicitly had no effect.

The erroring part of the verbose output is the following concluding entries:

config.status: creating src/port/port-tclsh
config.status: creating src/config.h
===> making all in vendor
/bin/sh: /Applications/Development/Xcode: No such file or directory
make: *** [all] Error 1
Command failed: CC=/usr/bin/cc ./configure --prefix=/opt/local --with-install-user=root --with-install-group=wheel --with-directory-mode=0755 --enable-readline && make -j8 SELFUPDATING=1 && make install SELFUPDATING=1
Exit code: 2
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

Change History (12)

comment:1 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Component: portsbase
Description: modified (diff)
Priority: HighNormal

You can't use spaces in toolchain paths, and that includes the path to Xcode. It's not just MacPorts itself that won't build this way; most of the software you can build with MacPorts won't work that way either. You'll have to rename your Xcode so it doesn't have spaces, and use xcode-select to select that new location.

comment:2 Changed 5 weeks ago by scrutinizer11

Ok, thanks for your response. I was suspecting it, however, aren't there ways to quote the path? I have MacPorts on another machine, running a different macOS version with Xcode containing spaces in its name, but updating worked there.

comment:3 Changed 5 weeks ago by scrutinizer11

MacPorts won't allow any modifications to its conf files. After reaching a dead end, I was forced to submit to its stubbornness and change the name of Xcode, despite the inconvenience of having the default name instead of my chosen one, which aligned better with my usage. It's an unfortunate outcome.

comment:4 in reply to:  2 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to scrutinizer11:

Ok, thanks for your response. I was suspecting it, however, aren't there ways to quote the path?

We could spend time fixing the MacPorts build system to work with paths with spaces. But you would encounter the same problem when actually trying to use MacPorts to build anything. See #54368. The path to the MacPorts source code also can't contain spaces. See #35910.

I have MacPorts on another machine, running a different macOS version with Xcode containing spaces in its name, but updating worked there.

Not sure why without more info. One hypothesis: Very old versions of macOS would use more components from the command line tools than from within Xcode and so wouldn't be affected by the Xcode path.

comment:5 in reply to:  3 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to scrutinizer11:

MacPorts won't allow any modifications to its conf files.

In a normal MacPorts install, its conf files are installed as root, so you need to be root (or use sudo) to edit them.

After reaching a dead end, I was forced to submit to its stubbornness and change the name of Xcode, despite the inconvenience of having the default name instead of my chosen one, which aligned better with my usage. It's an unfortunate outcome.

Sorry about that, but Unix build systems don't like paths containing spaces, and that's the world MacPorts operates in.

comment:6 Changed 5 weeks ago by scrutinizer11

I know I have to use sudo, but even that made no difference. Running selfupdate immediately reverses all changes. The other machine I mentioned was 10.7.5 I use occasionally.

Last edited 5 weeks ago by scrutinizer11 (previous) (diff)

comment:7 Changed 5 weeks ago by jmroot (Joshua Root)

The config files, by which I mean /opt/local/etc/macports/*.conf, are not reverted by selfupdate. The corresponding .default files are, and so are a number of files elsewhere that contain values discovered at build time.

comment:8 Changed 5 weeks ago by scrutinizer11

However, can you use these files to modify the developer_dir to guarantee it sticks? If affirmative, is it macports.conf?

comment:9 in reply to:  8 Changed 5 weeks ago by jmroot (Joshua Root)

Replying to scrutinizer11:

However, can you use these files to modify the developer_dir to guarantee it sticks? If affirmative, is it macports.conf?

Yes and yes.

comment:10 Changed 5 weeks ago by jmroot (Joshua Root)

However it's not clear from the provided log fragment that the path causing the error is even being obtained from the developer_dir variable.

comment:11 Changed 5 weeks ago by jmroot (Joshua Root)

In 7fbe0c8a92e21374f84faf082ba9d66adf51e2b8/macports-base (master):

Makefiles: quote $(MAKE)

See: #72582

comment:12 Changed 5 weeks ago by jmroot (Joshua Root)

It appears that /usr/bin/make will set $MAKE to the path to make inside Xcode.app, which will include any spaces in that path without escaping.

Note: See TracTickets for help on using tickets.