{"id":13441863,"url":"https://github.com/Z3Prover/z3","last_synced_at":"2025-03-20T13:31:10.166Z","repository":{"id":29408849,"uuid":"32944298","full_name":"Z3Prover/z3","owner":"Z3Prover","description":"The Z3 Theorem Prover","archived":false,"fork":false,"pushed_at":"2024-10-18T22:41:45.000Z","size":136189,"stargazers_count":10277,"open_issues_count":152,"forks_count":1480,"subscribers_count":181,"default_branch":"master","last_synced_at":"2024-10-19T14:19:37.530Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Z3Prover.png","metadata":{"files":{"readme":"README-CMake.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-03-26T18:16:07.000Z","updated_at":"2024-10-19T08:07:22.000Z","dependencies_parsed_at":"2023-12-19T17:26:16.015Z","dependency_job_id":"95854638-22d9-47ee-8106-f79b9ff11358","html_url":"https://github.com/Z3Prover/z3","commit_stats":{"total_commits":15684,"total_committers":315,"mean_commits":49.79047619047619,"dds":"0.42890844172404996","last_synced_commit":"d8156aeff31fb224531b026daacfafe2222f00e7"},"previous_names":[],"tags_count":45,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Z3Prover%2Fz3","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Z3Prover%2Fz3/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Z3Prover%2Fz3/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Z3Prover%2Fz3/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Z3Prover","download_url":"https://codeload.github.com/Z3Prover/z3/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":221337631,"owners_count":16800329,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T03:01:38.990Z","updated_at":"2025-03-20T13:31:10.159Z","avatar_url":"https://github.com/Z3Prover.png","language":"C++","readme":"# Z3's CMake build system\n\n[CMake](https://cmake.org/) is a \"meta build system\" that reads a description\nof the project written in the ``CMakeLists.txt`` files and emits a build\nsystem for that project of your choice using one of CMake's \"generators\".\nThis allows CMake to support many different platforms and build tools.\nYou can run ``cmake --help`` to see the list of supported \"generators\"\non your platform. Example generators include \"UNIX Makefiles\" and \"Visual Studio\n12 2013\".\n\n## Getting started\n\n### Fixing a polluted source tree\n\nIf you have never used the python build system you can skip this step.\n\nThe existing Python build system creates generated source files in\nthe source tree. The CMake build system will refuse to work if it\ndetects this so you need to clean your source tree first.\n\nTo do this run the following in the root of the repository\n\n```\ngit clean -nx src\n```\n\nThis will list everything that will be removed. If you are happy\nwith this then run.\n\n```\ngit clean -fx src\n```\n\nwhich will remove the generated source files.\n\n### Unix Makefiles\n\nRun the following in the top level directory of the Z3 repository.\n\n```\nmkdir build\ncd build\ncmake -G \"Unix Makefiles\" ../\nmake -j4 # Replace 4 with an appropriate number\n```\n\nNote that on some platforms \"Unix Makefiles\" is the default generator so on those\nplatforms you don't need to pass ``-G \"Unix Makefiles\"`` command line option to\n``cmake``.\n\nNote there is nothing special about the ``build`` directory name here. You can call\nit whatever you like.\n\nNote the \"Unix Makefile\" generator is a \"single\" configuration generator which\nmeans you pick the build type (e.g. ``Debug``, ``Release``) when you invoke CMake.\nYou can set the build type by passing it to the ``cmake`` invocation like so:\n\n```\ncmake -G \"Unix Makefiles\" -DCMAKE_BUILD_TYPE=Release ../\n```\n\nSee the section on \"Build Types\" for the different CMake build types.\n\nIf you wish to use a different compiler set the CXX and CC environment variables\npassed to cmake. This must be done at the very first invocation to ``cmake``\nin the build directory because once configuration has happened the compiler\nis fixed. If you want to use a different compiler to the one you have already\nconfigured you either need to make a new build directory or delete the contents\nof the current build directory and start again.\n\nFor example to use clang the ``cmake `` line would be\n\n```\nCC=clang CXX=clang++ cmake ../\n```\n\nNote that CMake build will detect the target architecture that compiler is set up\nto build for and the generated build system will build for that architecture.\nIf there is a way to tell your compiler to build for a different architecture via\ncompiler flags then you can set the ``CFLAGS`` and ``CXXFLAGS`` environment variables\nto have the build target that architecture.\n\nFor example if you are on a x86_64 machine and you want to do a 32-bit build and have\na multilib version of GCC you can run ``cmake`` like this\n\n```\nCFLAGS=\"-m32\" CXXFLAGS=\"-m32\" CC=gcc CXX=g++ cmake ../\n```\n\nNote like with the ``CC`` and ``CXX`` flags this must be done on the very first invocation\nto CMake in the build directory.\n\n### Adding Z3 as a dependency to a CMAKE Project\n\nCMake's [FetchContent](https://cmake.org/cmake/help/latest/module/FetchContent.html) allows\nthe fetching and populating of an external project. This is useful when a certain version\nof z3 is required that may not match with the system version. With the following code in the \ncmake file of your project, z3 version 4.12.1 is downloaded to the build directory and the\ncmake targets are added to the project:\n\n```\nFetchContent_Declare(z3\n        GIT_REPOSITORY https://github.com/Z3Prover/z3\n        GIT_TAG        z3-4.12.1\n)\nFetchContent_MakeAvailable(z3)\n```\n\nThe header files can be added to the included directories as follows:\n\n```\ninclude_directories( ${z3_SOURCE_DIR}/src/api )\n```\n\nFinally, the z3 library can be linked to a `yourTarget` using\n\n```\ntarget_link_libraries(yourTarget libz3)\n```\nNote that this is `libz3` not `z3` (`libz3` refers to the library target from `src/CMakeLists.txt`).\n\n\n\n### Ninja\n\n[Ninja](https://ninja-build.org/) is a simple build system that is built for speed.\nIt can be significantly faster than \"UNIX Makefile\"s because it is not a recursive\nbuild system and thus doesn't create a new process every time it traverses into a directory.\nNinja is particularly appropriate if you want fast incremental building.\n\nBasic usage is as follows:\n\n```\nmkdir build\ncd build\ncmake -G \"Ninja\" ../\nninja\n```\n\nNote the discussion of the ``CC``, ``CXX``, ``CFLAGS`` and ``CXXFLAGS`` for \"Unix Makefiles\"\nalso applies here.\n\nNote also that like the \"Unix Makefiles\" generator, the \"Ninja\" generator is a single configuration\ngenerator so you pick the build type when you invoke ``cmake`` by passing ``CMAKE_BUILD_TYPE=\u003cbuild_type\u003e``\nto ``cmake``. See the section on \"Build Types\".\n\nNote that Ninja runs in parallel by default. Use the ``-j`` flag to change this.\n\nNote that Ninja also runs on Windows. You just need to run ``cmake`` in an\nenvironment where the compiler can be found. If you have Visual Studio\ninstalled it typically ships with a \"Developer Command Prompt Window\" that you\ncan use which has the environment variables setup for you.\n\n### NMake\n\nNMake is a build system that ships with Visual Studio. You are advised to use\nNinja instead which is significantly faster due to supporting concurrent\nbuilds. However CMake does support NMake if you wish to use it. Note that\nNMake is a single configuration generator so you must set ``CMAKE_BUILD_TYPE``\nto set the build type.\n\nBasic usage:\n\n1. Launch the \"Developer Command Prompt Windows\"\n2. Change to the root of the Z3 repository\n\n```\nmkdir build\ncd build\ncmake -G \"NMake Makefiles\" ../\nnmake\n```\n\n### Visual Studio\n\nVisual Studio 19 comes with integrated support for CMake.\nIt suffices to open the (z3) folder where this file and the Z3 project CMakeLists.txt resides, \nand Visual Studio does the rest.\n\nFor legacy versions of Visual Studio a process is as follows:\nFor the Visual Studio generators you need to know which version of \nVisual Studio you wish to use and also what architecture you want to build for.\n\nWe'll use the ``cmake-gui`` here as it is easier to pick the right generator but this can\nbe scripted if need be.\n\nHere are the basic steps:\n\n1. Create an empty build directory\n2. Start the cmake-gui program\n3. Set \"where is the source code\" to the root of the Z3 project repository. You can do this by pressing\n   the \"Browse Source...\" button and picking the directory.\n4. Set \"where to build the binaries\" to the empty build directory you just created. You can do this\n   by pressing the \"Browse build...\" button and picking the directory.\n5. Press the \"Configure\" button\n6. A window will appear asking you to pick the generator to use. Pick the\n   generator that matches the version of Visual Studio you are using. Note also\n   that some of the generator names contain ``Win64`` (e.g. ``Visual Studio 12\n   2013 Win64``) this indicates a x86 64-bit build. Generator names without\n   this (e.g. ``Visual Studio 12 2013``) are x86 32-bit build.\n7. Press the \"Finish\" button and wait for CMake to finish it's first configure.\n8. A set of configuration options will appear which will affect various aspects of the build.\n   Change them as you desire. If you change a set of options press the \"Configure\"\n   again. Additional options may appear when you do this.\n9. When you have finished changing configuration options press the \"Generate\" button.\n10. When generation is done close cmake-gui.\n11. In the build directory open the generated ``Z3.sln`` solution file created by CMake with\n    Visual Studio.\n12. In Visual Studio pick the build type (e.g. ``Debug``, ``Release``) you want.\n13. Click \"BUILD \u003e Build Solution\".\n\nNote that unlike the \"Unix Makefile\" and \"Ninja\" generators the Visual Studio generators\nare multi-configuration generators which means you don't set the build type when invoking\nCMake. Instead you set the build type inside Visual Studio. See the \"Build Type\" section\nfor more information.\n\n### General workflow\n\nThe general workflow when using CMake is the following\n\n1. Create a new build directory\n2. Configure the project\n3. Generate the build system\n4. Invoke the build system to build the project\n\nTo perform steps 2 and 3 you can choose from three different tools\n\n* cmake\n* ccmake\n* cmake-gui\n\n``cmake`` is a command line tool and is what you should use if you are\nwriting a script to build Z3. This tool performs steps 1 and 2 in one\ngo without user interaction. The ``ccmake`` and ``cmake-gui`` tools are\nmore interactive and allow you to change various options. In both these\ntools the basic steps to follow are:\n\n1. Configure.\n2. Change any options you wish. Every time you change a set of options\n   You should configure again. This may cause new options to appear\n3. Generate.\n\nFor information see https://cmake.org/runningcmake/\n\nNote when invoking CMake you give it the path to the source directory.\nThis is the top-level directory in the Z3 repository containing a\n``CMakeLists.txt``. That file should contain the line ``project(Z3 C CXX)``.\nIf you give it a path deeper into the Z3 repository (e.g. the ``src`` directory)\nthe configure step will fail.\n\n## Build Types\n\nSeveral build types are supported.\n\n* Release\n* Debug\n* RelWithDebInfo\n* MinSizeRel\n\nFor the single configuration generators (e.g. \"Unix Makefile\" and \"Ninja\") you set the\nbuild type when invoking ``cmake`` by passing ``-DCMAKE_BUILD_TYPE=\u003cbuild_type\u003e`` where\n``\u003cbuild_type\u003e`` is one of the build types specified above.\n\nFor multi-configuration generators (e.g. Visual Studio) you don't set the build type\nwhen invoking CMake and instead set the build type within Visual Studio itself.\n\n## Useful options\n\nThe following useful options can be passed to CMake whilst configuring.\n\n* ``CMAKE_BUILD_TYPE`` - STRING. The build type to use. Only relevant for single configuration generators (e.g. \"Unix Makefile\" and \"Ninja\").\n* ``CMAKE_INSTALL_BINDIR`` - STRING. The path to install z3 binaries (relative to ``CMAKE_INSTALL_PREFIX``), e.g. ``bin``.\n* ``CMAKE_INSTALL_INCLUDEDIR`` - STRING. The path to install z3 include files (relative to ``CMAKE_INSTALL_PREFIX``), e.g. ``include``.\n* ``CMAKE_INSTALL_LIBDIR`` - STRING. The path to install z3 libraries (relative to ``CMAKE_INSTALL_PREFIX``), e.g. ``lib``.\n* ``CMAKE_INSTALL_PREFIX`` - STRING. The install prefix to use (e.g. ``/usr/local/``).\n* ``CMAKE_INSTALL_PKGCONFIGDIR`` - STRING. The path to install pkgconfig files.\n* ``CMAKE_INSTALL_PYTHON_PKG_DIR`` - STRING. The path to install the z3 python bindings. This can be relative (to ``CMAKE_INSTALL_PREFIX``) or absolute.\n* ``CMAKE_INSTALL_Z3_CMAKE_PACKAGE_DIR`` - STRING. The path to install CMake package files (e.g. ``/usr/lib/cmake/z3``).\n* ``CMAKE_INSTALL_API_BINDINGS_DOC`` - STRING. The path to install documentation for API bindings.\n* ``Python3_EXECUTABLE`` - STRING. The python executable to use during the build.\n* ``Z3_ENABLE_TRACING_FOR_NON_DEBUG`` - BOOL. If set to ``TRUE`` enable tracing in non-debug builds, if set to ``FALSE`` disable tracing in non-debug builds. Note in debug builds tracing is always enabled.\n* ``Z3_BUILD_LIBZ3_SHARED`` - BOOL. If set to ``TRUE`` build libz3 as a shared library otherwise build as a static library.\n* ``Z3_ENABLE_EXAMPLE_TARGETS`` - BOOL. If set to ``TRUE`` add the build targets for building the API examples.\n* ``Z3_USE_LIB_GMP`` - BOOL. If set to ``TRUE`` use the GNU multiple precision library. If set to ``FALSE`` use an internal implementation.\n* ``Z3_BUILD_PYTHON_BINDINGS`` - BOOL. If set to ``TRUE`` then Z3's python bindings will be built.\n* ``Z3_INSTALL_PYTHON_BINDINGS`` - BOOL. If set to ``TRUE`` and ``Z3_BUILD_PYTHON_BINDINGS`` is ``TRUE`` then running the ``install`` target will install Z3's Python bindings.\n* ``Z3_BUILD_DOTNET_BINDINGS`` - BOOL. If set to ``TRUE`` then Z3's .NET bindings will be built.\n* ``Z3_INSTALL_DOTNET_BINDINGS`` - BOOL. If set to ``TRUE`` and ``Z3_BUILD_DOTNET_BINDINGS`` is ``TRUE`` then running the ``install`` target will install Z3's .NET bindings.\n* ``Z3_DOTNET_CSC_EXECUTABLE`` - STRING. The path to the C# compiler to use. Only relevant if ``Z3_BUILD_DOTNET_BINDINGS`` is set to ``TRUE``.\n* ``Z3_DOTNET_GACUTIL_EXECUTABLE`` - STRING. The path to the gacutil program to use. Only relevant if ``BUILD_DOTNET_BINDINGS`` is set to ``TRUE``.\n* ``Z3_BUILD_JAVA_BINDINGS`` - BOOL. If set to ``TRUE`` then Z3's Java bindings will be built.\n* ``Z3_INSTALL_JAVA_BINDINGS`` - BOOL. If set to ``TRUE`` and ``Z3_BUILD_JAVA_BINDINGS`` is ``TRUE`` then running the ``install`` target will install Z3's Java bindings.\n* ``Z3_JAVA_JAR_INSTALLDIR`` - STRING. The path to directory to install the Z3 Java ``.jar`` file. This path should be relative to ``CMAKE_INSTALL_PREFIX``.\n* ``Z3_JAVA_JNI_LIB_INSTALLDIRR`` - STRING. The path to directory to install the Z3 Java JNI bridge library. This path should be relative to ``CMAKE_INSTALL_PREFIX``.\n* ``Z3_INCLUDE_GIT_DESCRIBE`` - BOOL. If set to ``TRUE`` and the source tree of Z3 is a git repository then the output of ``git describe`` will be included in the build.\n* ``Z3_INCLUDE_GIT_HASH`` - BOOL. If set to ``TRUE`` and the source tree of Z3 is a git repository then the git hash will be included in the build.\n* ``Z3_BUILD_DOCUMENTATION`` - BOOL. If set to ``TRUE`` then documentation for the API bindings can be built by invoking the ``api_docs`` target.\n* ``Z3_INSTALL_API_BINDINGS_DOCUMENTATION`` - BOOL. If set to ``TRUE`` and ``Z3_BUILD_DOCUMENTATION` is ``TRUE`` then documentation for API bindings will be installed\n    when running the ``install`` target.\n* ``Z3_ALWAYS_BUILD_DOCS`` - BOOL. If set to ``TRUE`` and ``Z3_BUILD_DOCUMENTATION`` is ``TRUE`` then documentation for API bindings will always be built.\n    Disabling this is useful for faster incremental builds. The documentation can be manually built by invoking the ``api_docs`` target.\n* ``Z3_LINK_TIME_OPTIMIZATION`` - BOOL. If set to ``TRUE`` link time optimization will be enabled.\n* ``Z3_ENABLE_CFI`` - BOOL. If set to ``TRUE`` will enable Control Flow Integrity security checks. This is only supported by MSVC and Clang and will\n    fail on other compilers. This requires Z3_LINK_TIME_OPTIMIZATION to also be enabled.\n* ``Z3_API_LOG_SYNC`` - BOOL. If set to ``TRUE`` will enable experimental API log sync feature.\n* ``WARNINGS_AS_ERRORS`` - STRING. If set to ``ON`` compiler warnings will be treated as errors. If set to ``OFF`` compiler warnings will not be treated as errors.\n    If set to ``SERIOUS_ONLY`` a subset of compiler warnings will be treated as errors.\n* ``Z3_C_EXAMPLES_FORCE_CXX_LINKER`` - BOOL. If set to ``TRUE`` the C API examples will request that the C++ linker is used rather than the C linker.\n* ``Z3_BUILD_EXECUTABLE`` - BOOL. If set to ``TRUE`` build the z3 executable. Defaults to ``TRUE`` unless z3 is being built as a submodule in which case it defaults to ``FALSE``.\n* ``Z3_BUILD_TEST_EXECUTABLES`` - BOOL. If set to ``TRUE`` build the z3 test executables. Defaults to ``TRUE`` unless z3 is being built as a submodule in which case it defaults to ``FALSE``.\n* ``Z3_SAVE_CLANG_OPTIMIZATION_RECORDS`` - BOOL. If set to ``TRUE`` saves Clang optimization records by setting the compiler flag ``-fsave-optimization-record``.\n* ``Z3_SINGLE_THREADED`` - BOOL. If set to ``TRUE`` compiles Z3 for single threaded mode.\n* ``Z3_POLLING_TIMER`` - BOOL. If set to ``TRUE`` compiles Z3 to use polling based timer instead of requiring a thread. This is useful for wasm builds and avoids spawning threads that interfere with how WASM is run.\n* ``Z3_ADDRESS_SANITIZE`` - BOOL. If set to ``TRUE`` compiles Z3 with address sanitization enabled. \n\n\nOn the command line these can be passed to ``cmake`` using the ``-D`` option. In ``ccmake`` and ``cmake-gui`` these can be set in the user interface.\n\nExample\n\n```\ncmake -DCMAKE_BUILD_TYPE=Release -DZ3_ENABLE_TRACING_FOR_NON_DEBUG=FALSE ../\n\n```\n\n## Z3 API Bindings\n\nZ3 exposes various language bindings for its API. Below are some notes on building\nand/or installing these bindings when building Z3 with CMake.\n\n### Java bindings\n\nThe CMake build uses the ``FindJava`` and ``FindJNI`` cmake modules to detect the\ninstallation of Java. If CMake fails to find your installation of Java set the\n``JAVA_HOME`` environment variable when invoking CMake so that it points at the\ncorrect location. For example\n\n```\nJAVA_HOME=/usr/lib/jvm/default cmake -DZ3_BUILD_JAVA_BINDINGS=ON ../\n```\nNote that the built ``.jar`` file is named ``com.microsoft.z3-VERSION.jar``\nwhere ``VERSION`` is the Z3 version. Under non Windows systems a\nsymbolic link named ``com.microsoft.z3.jar`` is provided. This symbolic\nlink is not created when building under Windows.\n\n## Developer/packager notes\n\nThese notes are help developers and packagers of Z3.\n\n### Install/Uninstall\n\nInstall and uninstall targets are supported. Use ``CMAKE_INSTALL_PREFIX`` to\nset the install prefix. If you also need to control which directories are\nused for install set the documented ``CMAKE_INSTALL_*`` options.\n\nTo install run\n\n```\nmake install\n```\n\nTo uninstall run\n\n```\nmake uninstall\n```\n\nNote that ``DESTDIR`` is supported for [staged installs](https://www.gnu.org/prep/standards/html_node/DESTDIR.html).\n\nTo install\n\n```\nmkdir staged\nmake install DESTDIR=/full/path/to/staged/\n```\n\nto uninstall\n\n```\nmake uninstall DESTDIR=/full/path/to/staged\n```\n\nThe above also works for Ninja but ``DESTDIR`` must be an environment variable instead.\n\n### Examining invoked commands\n\nIf you are using the \"UNIX Makefiles\" generator and want to see exactly the commands that are\nbeing run you can pass ``VERBOSE=1`` to make.\n\n```\nmake VERBOSE=1\n```\n\nIf you are using Ninja you can use the ``-v`` flag.\n\n### Additional targets\n\nTo see the list of targets run\n\n```\nmake help\n```\n\nThere are a few special targets:\n\n* ``clean`` all the built targets in the current directory and below\n* ``edit_cache`` will invoke one of the CMake tools (depending on which is available) to let you change configuration options.\n* ``rebuild_cache`` will reinvoke ``cmake`` for the project.\n* ``api_docs`` will build the documentation for the API bindings.\n\n### Setting build type specific flags\n\nThe build system supports single configuration and multi-configuration generators. This means\nit is not possible to know the build type at configure time and therefore ``${CMAKE_BUILD_TYPE}``\nshould not be conditionally used to set compiler flags or definitions. Instead you should use Generator expressions which are evaluated by the generator.\n\nFor example\n\n```\n$\u003c$\u003cCONFIG:Debug\u003e:Z3DEBUG\u003e\n```\n\nIf the build type at build time is ``Debug`` this evaluates to ``Z3DEBUG`` but evaluates to nothing for all other configurations. You can see examples of this in the ``CMakeLists.txt`` files.\n\n### File-globbing\n\nIt is tempting use file-globbing in ``CMakeLists.txt`` to find a set for files matching a pattern and\nuse them as the sources to build a target. This however is a bad idea because it prevents CMake from knowing when it needs to rerun itself. This is why source file names are explicitly listed in the ``CMakeLists.txt`` so that when changes are made the source files used to build a target automatically triggers a rerun of CMake.\n\nLong story short. Don't use file globbing.\n\n### Serious warning flags\n\nBy default the `WARNINGS_AS_ERRORS` flag is set to `SERIOUS_ONLY` which means\nsome warnings will be treated as errors. These warnings are controlled by the\nrelevant `*_WARNINGS_AS_ERRORS` list defined in\n`cmake/compiler_warnings.cmake`.\n\nAdditional warnings should only be added here if the warnings has no false\npositives.\n","funding_links":[],"categories":["C++","Tools","Reversing","Formal Verification","Resources","Solvers","Repos","Code Analyzers","Programming/Comp Sci/SE Things"],"sub_categories":["Symbolic Execution SAT and SMT Solvers","By Purpose","SMT Solvers","Programming Languages that Compile zk-SNARK Circuits and Proofs","Reversing/Binary Analysis"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FZ3Prover%2Fz3","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FZ3Prover%2Fz3","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FZ3Prover%2Fz3/lists"}