Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build, depends: fix compilation with XCode 15 #2747

Merged
merged 3 commits into from
Mar 6, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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
}
Loading