95dbf30fb9
All platforms: - rename scripts/ to tools/: Bazelisk expects to find its wrapper script (used by the Mac changes below) in tools/. Rather than have a separate scripts/ and tools/, it's simpler to just move everything into tools/. - wheel outputs and binary bundles now go into .bazel/out/dist. While not technically Bazel build products, doing it this way ensures they get cleaned up when 'bazel clean' is run, and it keeps them out of the source folder. - update to the latest Bazel Windows changes: - bazel.bat has been removed, and tools\setup-env.bat has been added. Other scripts like .\run.bat will automatically call it to set up the environment. - because Bazel is now on the path, you can 'bazel test ...' from any folder, instead of having to do \anki\bazel. - the bat files can handle being called from any working directory, so things like running "\anki\tools\python" from c:\ will work. - build installer as part of bundling process Mac changes: - `arch -arch x86_64 bazel ...` will now automatically use a different build root, so that it is cheap to switch back and forth between archs on a new Mac. - tools/run-qt* will now automatically use Rosetta - disable jemalloc in Mac x86 build for now, as it won't build under Rosetta (perhaps due to its build scripts using $host_cpu instead of $target_cpu) - create app bundle as part of bundling process Linux changes: - remove arm64 orjson workaround in Linux bundle, as without a readily-available, relatively distro-agonstic PyQt/Qt build we can use, the arm64 Linux bundle is of very limited usefulness. - update Docker files for release build - include fcitx5 in both the qt5 and qt6 bundles - create tarballs as part of the bundling process
46 lines
2.0 KiB
Plaintext
46 lines
2.0 KiB
Plaintext
# By default Rust will not export dynamic symbols from built executables.
|
|
# Python symbols need to be exported from executables in order for that
|
|
# executable to load Python extension modules, which are shared libraries.
|
|
# Otherwise, the extension module / shared library is unable to resolve
|
|
# Python symbols. This file contains target-specific configuration
|
|
# overrides to export dynamic symbols from executables.
|
|
#
|
|
# Ideally we would achieve this functionality via the build.rs build
|
|
# script. But custom compiler flags via build scripts apparently only
|
|
# support limited options.
|
|
|
|
[target.i686-unknown-linux-gnu]
|
|
rustflags = ["-C", "link-args=-Wl,-export-dynamic"]
|
|
|
|
[target.x86_64-unknown-linux-gnu]
|
|
rustflags = ["-C", "link-args=-Wl,-export-dynamic"]
|
|
|
|
[target.aarch64-unknown-linux-gnu]
|
|
rustflags = ["-C", "link-args=-Wl,-export-dynamic"]
|
|
|
|
[target.aarch64-apple-darwin]
|
|
rustflags = ["-C", "link-args=-rdynamic"]
|
|
|
|
[target.x86_64-apple-darwin]
|
|
rustflags = ["-C", "link-args=-rdynamic"]
|
|
|
|
# The Windows standalone_static distributions use the static CRT (/MT compiler
|
|
# flag). By default, Rust will build with the dynamically linked / DLL CRT
|
|
# (/MD compiler flag). `pyoxidizer build` should adjust RUSTFLAGS automatically
|
|
# when a standalone_static distribution is being used. But if invoking `cargo`
|
|
# directly, you'll need to override the default CRT linkage by either passing
|
|
# RUSTFLAGS="-C target-feature=+crt-static" or by commenting out the lines
|
|
# below. Note that use of `target-feature=+crt-static` will prevent
|
|
# standalone_dynamic distributions from working.
|
|
#
|
|
# The standalone_static distributions also have duplicate symbols and some
|
|
# build configurations will result in hard linker errors because of this. We
|
|
# also add the /FORCE:MULTIPLE linker argument to prevent this from being a
|
|
# fatal error.
|
|
|
|
#[target.i686-pc-windows-msvc]
|
|
#rustflags = ["-C", "target-feature=+crt-static", "-C", "link-args=/FORCE:MULTIPLE"]
|
|
#
|
|
#[target.x86_64-pc-windows-msvc]
|
|
#rustflags = ["-C", "target-feature=+crt-static", "-C", "link-args=/FORCE:MULTIPLE"]
|