Skip to content

Commit

Permalink
Merge pull request #2747 from div72/fix-xcode15
Browse files Browse the repository at this point in the history
build, depends: fix compilation with XCode 15
  • Loading branch information
jamescowens committed Mar 6, 2024
2 parents 493b739 + b84ee23 commit 9f9df56
Show file tree
Hide file tree
Showing 5 changed files with 70 additions and 3 deletions.
12 changes: 11 additions & 1 deletion configure.ac
Original file line number Diff line number Diff line change
Expand Up @@ -1009,10 +1009,20 @@ dnl Check for Boost libs
AX_BOOST_BASE([MINIMUM_REQUIRED_BOOST])
AX_BOOST_SYSTEM
AX_BOOST_FILESYSTEM
AX_BOOST_THREAD
AX_BOOST_ZLIB
AX_BOOST_IOSTREAMS

dnl Prevent use of std::unary_function, which was removed in C++17,
dnl and will generate warnings with newer compilers for Boost
dnl older than 1.80.
dnl See: https://github.com/boostorg/config/pull/430.
AX_CHECK_PREPROC_FLAG([-DBOOST_NO_CXX98_FUNCTION_BASE], [BOOST_CPPFLAGS="$BOOST_CPPFLAGS -DBOOST_NO_CXX98_FUNCTION_BASE"], [], [$CXXFLAG_WERROR],
[AC_LANG_PROGRAM([[#include <boost/config.hpp>]])])

dnl AX_BOOST_THREAD check also triggers the same issue, so it has to be checked after
dnl setting -DBOOST_NO_CXX98_FUNCTION_BASE.
AX_BOOST_THREAD

dnl Boost 1.56 through 1.62 allow using std::atomic instead of its own atomic
dnl counter implementations. In 1.63 and later the std::atomic approach is default.
m4_pattern_allow(DBOOST_AC_USE_STD_ATOMIC) dnl otherwise it's treated like a macro
Expand Down
2 changes: 1 addition & 1 deletion depends/packages/boost.mk
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ ifneq (,$(findstring clang,$($(package)_cxx)))
endif
$(package)_archiver_$(host_os)=$($(package)_ar)
$(package)_config_libraries=filesystem,system,thread,test,iostreams
$(package)_cxxflags+=-std=c++17
$(package)_cxxflags+=-std=c++17 -DBOOST_NO_CXX98_FUNCTION_BASE
$(package)_cxxflags_linux=-fPIC
$(package)_cxxflags_android=-fPIC
endef
Expand Down
2 changes: 1 addition & 1 deletion depends/packages/libzip.mk
Original file line number Diff line number Diff line change
Expand Up @@ -42,5 +42,5 @@ define $(package)_build_cmds
endef

define $(package)_stage_cmds
$(MAKE) DESTDIR=$($(package)_staging_dir) install
$(MAKE) DESTDIR=$($(package)_staging_dir) install -j1
endef
2 changes: 2 additions & 0 deletions depends/packages/qt.mk
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ $(package)_patches += qtbase-moc-ignore-gcc-macro.patch
$(package)_patches += no_qrhi.patch
$(package)_patches += drop_lrelease_dependency.patch
$(package)_patches += subdirs.pro
$(package)_patches += fix-macos-linker.patch

$(package)_qttranslations_file_name=qttranslations-$($(package)_suffix)
$(package)_qttranslations_sha256_hash=c92af4171397a0ed272330b4fa0669790fcac8d050b07c8b8cc565ebeba6735e
Expand Down Expand Up @@ -255,6 +256,7 @@ endef
# CROSS_LIBRARY_PATH. See #15277.
define $(package)_preprocess_cmds
rm -f $(BASEDIR)/.qmake.stash && \
patch -p1 -i $($(package)_patch_dir)/fix-macos-linker.patch && \
patch -p1 -i $($(package)_patch_dir)/drop_lrelease_dependency.patch && \
patch -p1 -i $($(package)_patch_dir)/dont_hardcode_pwd.patch && \
patch -p1 -i $($(package)_patch_dir)/dont_hardcode_x86_64.patch && \
Expand Down
55 changes: 55 additions & 0 deletions depends/patches/qt/fix-macos-linker.patch
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
qmake: Don't error out if QMAKE_DEFAULT_LIBDIRS is empty on macOS

The new linker in Xcode 15 doesn't provide any default linker or
framework paths when requested via -v, but still seems to use the
default paths documented in the ld man page.

We trust that linker will do the right thing, even if we don't
know of its default linker paths.

We also need to opt out of the default fallback logic to
set the libdirs to /lib and /usr/lib.

This may result in UnixMakefileGenerator::findLibraries finding
different libraries than expected, if additional paths are
passed with -L, which will then take precedence for qmake,
even if the linker itself will use the library from the
SDK's default paths. This should hopefully not be an issue
in practice, as we don't turn -lFoo into absolute paths in
qmake, so the only risk is that we're picking up the wrong
prl files and adding additional dependencies that the lib
in the SDK doesn't have.

Upstream commits:
- Qt 5.15.16: Not yet publicly available.
- Qt dev: cdf64b0e47115cc473e1afd1472b4b09e130b2a5

For other Qt branches see
https://codereview.qt-project.org/q/I2347b26e2df0828471373b0e15b8c9089274c65d

--- old/qtbase/mkspecs/features/toolchain.prf
+++ new/qtbase/mkspecs/features/toolchain.prf
@@ -288,9 +288,12 @@ isEmpty($${target_prefix}.INCDIRS) {
}
}
}
- isEmpty(QMAKE_DEFAULT_LIBDIRS)|isEmpty(QMAKE_DEFAULT_INCDIRS): \
+ isEmpty(QMAKE_DEFAULT_INCDIRS): \
!integrity: \
- error("failed to parse default search paths from compiler output")
+ error("failed to parse default include paths from compiler output")
+ isEmpty(QMAKE_DEFAULT_LIBDIRS): \
+ !integrity:!darwin: \
+ error("failed to parse default library paths from compiler output")
QMAKE_DEFAULT_LIBDIRS = $$unique(QMAKE_DEFAULT_LIBDIRS)
} else: ghs {
cmd = $$QMAKE_CXX $$QMAKE_CXXFLAGS -$${LITERAL_HASH} -o /tmp/fake_output /tmp/fake_input.cpp
@@ -412,7 +415,7 @@ isEmpty($${target_prefix}.INCDIRS) {
QMAKE_DEFAULT_INCDIRS = $$split(INCLUDE, $$QMAKE_DIRLIST_SEP)
}

- unix:if(!cross_compile|host_build) {
+ unix:!darwin:if(!cross_compile|host_build) {
isEmpty(QMAKE_DEFAULT_INCDIRS): QMAKE_DEFAULT_INCDIRS = /usr/include /usr/local/include
isEmpty(QMAKE_DEFAULT_LIBDIRS): QMAKE_DEFAULT_LIBDIRS = /lib /usr/lib
}

0 comments on commit 9f9df56

Please sign in to comment.