Opened 3 years ago

Last modified 20 months ago

#63318 new defect

makefile portgroup's compiler wrappers break bastet universal variant

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: portgroup Cc: cjones051073 (Chris Jones)
Port:

Description

bastet used to install with the universal variant. Now it does not, because the makefile portgroup was changed to use compiler wrappers that contain -arch flags. The error is:

/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-ryandesign-fork_games_bastet/bastet/work/compwrap/cxx/usr/bin/clang++ -MM Ui.cpp Block.cpp Well.cpp BlockPosition.cpp Config.cpp BlockChooser.cpp BastetBlockChooser.cpp main.cpp Test.cpp> depend
clang: error: cannot use 'dependencies' output with multiple -arch options

Note that the invocation of clang++ does not have -arch flags, as they are not needed and would cause problems. But the clang++ wrapper script contains -arch flags, which cause the problem.

Change History (5)

comment:1 Changed 3 years ago by cjones051073 (Chris Jones)

The compiler wrapper PG does not by itself set the -arch flag, it simply propagates whatever the flags are that have been configured, so if it worked before it is because the port was ignoring these.

To disable this, just add

compwrap.add_compiler_flags no

to the bastet port file.

comment:2 in reply to:  1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to cjones051073:

The compiler wrapper PG does not by itself set the -arch flag, it simply propagates whatever the flags are that have been configured, so if it worked before it is because the port was ignoring these.

I'm not sure what you mean. Previously, the bastet port built correctly, for the correct architectures, whether universal or not. Now, it doesn't, due to changes in the makefile portgroup (the inclusion of the compiler_wrapper portgroup). These same changes may cause these same errors in countless other ports that use the makefile portgroup and worked correctly before these changes.

The bastet portfile does not contain any code that adjusts -arch flags; it relies entirely on MacPorts base putting the -arch flags into CFLAGS, CXXFLAGS, and LDFLAGS and the bastet build system uses those where appropriate.

When compiling, the C compiler must be invoked with CFLAGS and the C++ compiler must be invoked with CXXFLAGS. When linking, the compiler must be invoked with LDFLAGS. When neither compiling nor linking but merely using the compiler to compute dependencies, which is what's happening here for bastet, it should not be invoked with -arch flags (should not use CFLAGS, CXXFLAGS, nor LDFLAGS) and yet because the compiler_wrapper portgroup evidently puts CXXFLAGS including -arch flags into the clang++ wrapper it is.

On my system the clang++ wrapper that the portgroup created for bastet contains:

#!/bin/bash
export CCACHE_DIR=/opt/local/var/macports/build/.ccache
exec /opt/local/bin/ccache /usr/bin/clang++   -I/opt/local/libexec/boost/1.76/include -Os -arch x86_64 -arch i386 -stdlib=libc++ -pipe ${MACPORTS_LEGACY_SUPPORT_CPPFLAGS}  "${@}" 

The log says:

DEBUG: compiler_wrapper: Creating /path/to/work/compwrap/cxx/usr/bin/clang++
DEBUG: compiler_wrapper:  -> Will embed ' -I/opt/local/libexec/boost/1.76/include -Os -arch x86_64 -arch i386 -stdlib=libc++' in cxx wrapper script
DEBUG: compiler_wrapper:  -> Will embed -pipe in cxx wrapper script
DEBUG: compiler_wrapper:  -> Will embed legacysupport flags in cxx wrapper script
DEBUG: compiler_wrapper:  -> Will use ccache compiler launcher in cxx wrapper script

To disable this, just add

compwrap.add_compiler_flags no

to the bastet port file.

...and the unknown number of other ports that worked before but now don't. Would it not be better to make no the default setting of this portgroup feature, and the handful of unusual ports that do not and for whatever reason cannot supply the correct flags when invoking the compiler can set it to yes? Or even, would it not be better to return the makefile portgroup to its previous functioning by not having it include the compiler_wrapper portgroup, and let ports that need that functionality include it themselves?

comment:3 Changed 3 years ago by cjones051073 (Chris Jones)

Embedding the compiler flags in my experience solves more problems than it solves. This is the first instance I have seen of if causing issues. That said, when used via the makefile PG it might make sense to disable the embedding by default (completely removing the wrapper PG would also be counter productive as we would then loose the fixes that provides, like a number of ports need it to correctly find boost, and it also helps with legacy support).

comment:5 Changed 20 months ago by mascguy (Christopher Nielsen)

Keywords: portgroup added

Add keyword portgroup, to pg-related tickets

Note: See TracTickets for help on using tickets.