Add Fuchsia support #478
Merged
Add Fuchsia support #478
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
cdotstout
force-pushed
the
master
branch
3 times, most recently
from
881ba15 to
a364725
Compare
Contributor
|
So the main problem I have about this is that we're not currently doing testing on fuschia and I haven't actually used fuschia. As a result, I'm reluctant to just take this because I don't understand how all of this works and because I'm afraid that we'll end up carelessly breaking this because of a lack of testing. I absolutely think that supporting fuschia with this loader would be a good thing, but I'd want to make sure it's proper support and not some afterthought that we end up breaking by mistake once people are counting on that support. Is there a way we could talk about what supporting fuschia would actually entail? If you prefer to talk off of the issue, my email is in the readme for this repo and we can always talk that way. |
MarkY-LunarG
reviewed
Oct 6, 2020
| # See the License for the specific language governing permissions and | ||
| # limitations under the License. | ||
|
|
||
| import("//build_overrides/build.gni") |
Collaborator
There was a problem hiding this comment.
Seems to also affect Android/Chromium. Has this been compiled for each?
Contributor
Author
There was a problem hiding this comment.
I haven't tested those builds manually. Is there a documented process I can follow?
Contributor
There was a problem hiding this comment.
Not really. I asked @mikes-lunarg to run this through the ANGLE build, which should do enough testing for us. I'll let him say how it works out.
Contributor
Author
There was a problem hiding this comment.
Sounds like @mikes-lunarg can help test the GN build.
MarkY-LunarG
reviewed
Oct 6, 2020
BUILD.gn
Outdated
Comment on lines
36
to
39
| cflags = [ | ||
| "-Wno-conversion", | ||
| "-Wno-extra-semi", | ||
| ] |
Collaborator
There was a problem hiding this comment.
Seems to also affect Android/Chromium. Has this been compiled for each?
Contributor
Author
There was a problem hiding this comment.
I haven't - sounds like @mikes-lunarg can help test the GN build.
MarkY-LunarG
reviewed
Oct 6, 2020
|
|
||
| ## Building on Fuchsia | ||
|
|
||
| Fuchsia uses the project's GN build system to integrate with the Fuchsia platform build. |
Collaborator
There was a problem hiding this comment.
Should we indicate that Fuchsia support is Alpha since the OS has not yet been released?
Contributor
Author
There was a problem hiding this comment.
Yes we should. @lenny-lunarg please go ahead and add the note.
lenny-lunarg
approved these changes
Oct 6, 2020
Contributor
lenny-lunarg
left a comment
lenny-lunarg
left a comment
There was a problem hiding this comment.
By and large, looks good to me.
The way you stick the dlopen implementation into another file kinda goes against our convention, but our system doesn't really work for longer implementations so I'm fine with this method. I might want to make the system a little more consistent across platforms at some point, but that can be done later.
I would like to see a note in the documentation somewhere about fuschia support being alpha quality at the moment. I can add that note if you like.
I don't see anything that's worth holding this up over, so I'm fine with merging this. I am going to wait until @mikes-lunarg has had a chance to test the GN build a little more thoroughly before I merge this, though.
| @@ -0,0 +1,207 @@ | |||
| vkAcquireNextImage2KHR | |||
Contributor
There was a problem hiding this comment.
Long term, we should try to get something to ensure that the functions in this file match those in vulkan-1.def. It's not that important right now, but whenever the next Vulkan minor release comes out it would be a good idea to have that.
Contributor
Author
There was a problem hiding this comment.
Sure. I'll file an issue after we merge this.
mikes-lunarg
reviewed
Oct 7, 2020
| public_deps = [ "$vulkan_headers_dir:vulkan_headers" ] | ||
| configs -= [ "//build/config/compiler:chromium_code" ] | ||
| configs += [ "//build/config/compiler:no_chromium_code" ] | ||
| if (build_with_chromium) { |
Collaborator
There was a problem hiding this comment.
This block in particular is breaking the ANGLE windows build. We may have been relying it on it to suppress additional warnings.
FAILED: obj/third_party/vulkan-loader/src/libvulkan/loader.obj
..\..\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe /nologo /showIncludes:user "-imsvc..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\ATLMFC\include" "-imsvc..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include" "-imsvc..\..\..\..\..\..\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" "-imsvc..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt" "-imsvc..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared" "-imsvc..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um" "-imsvc..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt" "-imsvc..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt" -DUSE_AURA=1 "-DCR_CLANG_REVISION=\"llvmorg-12-init-5627-gf086e85e-2\"" -D_HAS_NODISCARD -DCOMPONENT_BUILD -D_LIBCPP_ABI_UNSTABLE -D_LIBCPP_ENABLE_NODISCARD -D_LIBCPP_NO_AUTO_LINK -D__STD_C -D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE -D_ATL_NO_OPENGL -D_WINDOWS -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS -DPSAPI_VERSION=2 -DWIN32 -D_SECURE_ATL -DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -DWIN32_LEAN_AND_MEAN -DNTDDI_VERSION=NTDDI_WIN10_VB -D_WIN32_WINNT=0x0A00 -DWINVER=0x0A00 -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DVULKAN_NON_CMAKE_BUILD "-DAPI_NAME=\"Vulkan\"" -DUSE_UNSAFE_FILE_SEARCH=1 -DVK_USE_PLATFORM_WIN32_KHR -I../.. -Igen -I../../third_party/vulkan-loader/src/loader/generated -I../../third_party/vulkan-loader/src/loader -I../../third_party/vulkan-headers/src/include -Wno-incompatible-pointer-types -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm -instcombine-lower-dbg-declare=0 -mllvm -enable-dse-memoryssa=false -fcomplete-member-pointers /Gy /FS /bigobj /utf-8 /Zc:twoPhase /Zc:sizedDealloc- /X /D__WRL_ENABLE_FUNCTION_STATICS__ -fmsc-version=1916 /guard:cf,nochecks /Zc:dllexportInlines- -m64 /Brepro -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -Xclang -fdebug-compilation-dir -Xclang . -no-canonical-prefixes /W4 -Wimplicit-fallthrough -Wunreachable-code -Wthread-safety -Wextra-semi /WX /wd4091 /wd4127 /wd4251 /wd4275 /wd4312 /wd4324 /wd4351 /wd4355 /wd4503 /wd4589 /wd4611 /wd4100 /wd4121 /wd4244 /wd4505 /wd4510 /wd4512 /wd4610 /wd4838 /wd4995 /wd4996 /wd4456 /wd4457 /wd4458 /wd4459 /wd4200 /wd4201 /wd4204 /wd4221 /wd4245 /wd4267 /wd4305 /wd4389 /wd4702 /wd4701 /wd4703 /wd4661 /wd4706 /wd4715 -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-psabi -Wno-ignored-pragma-optimize -Wno-implicit-int-float-conversion -Wno-final-dtor-non-final-class -Wno-builtin-assume-aligned-alignment -Wno-deprecated-copy -Wno-non-c-typedef-for-linkage -Wmax-tokens /Od /Ob0 /GF /Z7 -gcodeview-ghash -Xclang -debug-info-kind=constructor -ftrivial-auto-var-init=pattern /MDd -Xclang -add-plugin -Xclang find-bad-constructs -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wno-conversion -Wno-extra-semi -Wno-unused-function /wd4201 /TC -Wno-implicit-fallthrough /c ../../third_party/vulkan-loader/src/loader/loader.c /Foobj/third_party/vulkan-loader/src/libvulkan/loader.obj /Fd"obj/third_party/vulkan-loader/src/libvulkan_c.pdb"
../../third_party/vulkan-loader/src/loader/loader.c(945,39): error: comparison of integers of different signs: 'int' and 'unsigned long long' [-Werror,-Wsign-compare]
for (i = 0; i < sizeof(known_drivers) / sizeof(known_drivers[0]); ++i) {
~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../third_party/vulkan-loader/src/loader/loader.c(975,58): error: comparison of integers of different signs: 'UINT' (aka 'unsigned int') and 'const int' [-Werror,-Wsign-compare]
if (description.VendorId == known_drivers[i].vendor_id) {
~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
../../third_party/vulkan-loader/src/loader/loader.c(4310,10): error: unused variable 'is_icd' [-Werror,-Wunused-variable]
bool is_icd = (data_file_type == LOADER_DATA_FILE_MANIFEST_ICD);
^
3 errors generated.
ninja: build stopped: subcommand failed.
Contributor
Author
There was a problem hiding this comment.
I've asked for assistance from the ANGLE team.
Collaborator
There was a problem hiding this comment.
FYI I also just pushed this to the ANGLE gerrit server to get more build coverage: https://chromium-review.googlesource.com/c/angle/angle/+/2457707
It is probably just a matter of tracking down the right set of warnings to turn off if we can't use the chromium_code/no_chromium_code configs.
Contributor
Author
There was a problem hiding this comment.
@mikes-lunarg I've uploaded another commit to hopefully fix; can you push again so we can retry angle? (I don't think I have permission to push a branch)
Contributor
Author
There was a problem hiding this comment.
I pushed a 3rd commit (removes an unused variable) and angle build looks good.
https://chromium-review.googlesource.com/c/angle/angle/+/2462718
Contributor
Author
|
I think GN builds are good to go. I was thinking of squashing the 3 commits, let me know if you prefer that I do that or not. @lenny-lunarg |
mikes-lunarg
approved these changes
Oct 9, 2020
Collaborator
mikes-lunarg
left a comment
mikes-lunarg
left a comment
There was a problem hiding this comment.
LGTM, angle build is much happier
Fuchsia (fuchsia.dev) builds with GN and uses a loader service to load the ICD into the application's address space. ANGLE builds have been verified. Reemoves unused variable is_icd.
gnoliyil
added a commit
to gnoliyil/Vulkan-Loader
that referenced
this pull request
Feb 18, 2025
This change merges the Fuchsia-forked Vulkan-Loader branch into the upstream. Since last update (KhronosGroup#478), there has been significant changes to the way for Vulkan Loader to get manifests and the way for Vulkan ICDs to get I/O access to GPU devices. Also, Fuchsia has completely dropped C bindings for the FIDL API which `dlopen_fuchsia.c` uses. This change makes the following changes: * Add `loader_extensions_fuchsia.{cc,h}`. This allows the Vulkan Loader to provide a way to allow I/O to GPU devices to the ICDs it opens. The extended ICD API is defined in https://fuchsia.dev/fuchsia-src/ contribute/governance/rfcs/0205_vulkan_loader and it's implemented on ICDs like Fuchsia's Intel Mesa ICD: https://fuchsia.googlesource.com/third_party/mesa/+/main/src/intel/ vulkan/anv_magma.c * Access data and manifest files from manifest file system FD: The Fuchsia Vulkan loader service provides manifests using a service-provided virtual file system. It creates these filesystems based on the contents of multiple ICD packages and services it receives through devfs. As a result, they must be constructed using a filesystem serving library and don't reflect anything on-disk (see https://fuchsia.dev/fuchsia-src/contribute/governance/ rfcs/0205_vulkan_loader#filesystem_serving for details). The service-provided file system can be only opened as an FD using Fuchsia's FDIO (https://fuchsia.googlesource.com/fuchsia/+/main/sdk/ lib/fdio) library. Thus, in order to read manifest files located in a directory opened as an FD, we need to add a `parent_dir_fd` param to the functions that read files, including `loader_get_json` and `add_data_files`. * Migrated to the C++ FIDL bindings. The old C bindings are not supported anymore and have been deleted from the Fuchsia tree. This change migrates `dlopen_fuchsia` to use the C++ wire bindings (https://fuchsia.dev/fuchsia-src/reference/ fidl/bindings/cpp-bindings) which is part of the Fuchsia SDK. Test: libvulkan builds on Fuchsia with the changes above. Bug: https://fxbug.dev/378964821 manifest Change-Id: I2af9f677d706d07193aecd2dcc4640ec602b138f
gnoliyil
added a commit
to gnoliyil/Vulkan-Loader
that referenced
this pull request
Feb 18, 2025
This change merges the Fuchsia-forked Vulkan-Loader branch into the upstream. Since last update (KhronosGroup#478), there has been significant changes to the way for Vulkan Loader to get manifests and the way for Vulkan ICDs to get I/O access to GPU devices. Also, Fuchsia has completely dropped C bindings for the FIDL API which `dlopen_fuchsia.c` uses. This change makes the following changes: * Add `loader_extensions_fuchsia.{cc,h}`. This allows the Vulkan Loader to provide a way to allow I/O to GPU devices to the ICDs it opens. The extended ICD API is defined in https://fuchsia.dev/fuchsia-src/ contribute/governance/rfcs/0205_vulkan_loader and it's implemented on ICDs like Fuchsia's Intel Mesa ICD: https://fuchsia.googlesource.com/third_party/mesa/+/main/src/intel/ vulkan/anv_magma.c * Access data and manifest files from manifest file system FD: The Fuchsia Vulkan loader service provides manifests using a service-provided virtual file system. It creates these filesystems based on the contents of multiple ICD packages and services it receives through devfs. As a result, they must be constructed using a filesystem serving library and don't reflect anything on-disk (see https://fuchsia.dev/fuchsia-src/contribute/governance/ rfcs/0205_vulkan_loader#filesystem_serving for details). The service-provided file system can be only opened as an FD using Fuchsia's FDIO (https://fuchsia.googlesource.com/fuchsia/+/main/sdk/ lib/fdio) library. Thus, in order to read manifest files located in a directory opened as an FD, we need to add a `parent_dir_fd` param to the functions that read files, including `loader_get_json` and `add_data_files`. * Migrated to the C++ FIDL bindings. The old C bindings are not supported anymore and have been deleted from the Fuchsia tree. This change migrates `dlopen_fuchsia` to use the C++ wire bindings (https://fuchsia.dev/fuchsia-src/reference/ fidl/bindings/cpp-bindings) which is part of the Fuchsia SDK. Test: libvulkan builds on Fuchsia with the changes above. Bug: https://fxbug.dev/378964821 Change-Id: I2af9f677d706d07193aecd2dcc4640ec602b138f
gnoliyil
added a commit
to gnoliyil/Vulkan-Loader
that referenced
this pull request
Feb 19, 2025
This change merges the Fuchsia-forked Vulkan-Loader branch into the upstream. Since last update (KhronosGroup#478), there has been significant changes to the way for Vulkan Loader to get manifests and the way for Vulkan ICDs to get I/O access to GPU devices. Also, Fuchsia has completely dropped C bindings for the FIDL API which `dlopen_fuchsia.c` uses. This change makes the following changes: * Add `loader_extensions_fuchsia.{cc,h}`. This allows the Vulkan Loader to provide a way to allow I/O to GPU devices to the ICDs it opens. The extended ICD API is defined in https://fuchsia.dev/fuchsia-src/ contribute/governance/rfcs/0205_vulkan_loader and it's implemented on ICDs like Fuchsia's Intel Mesa ICD: https://fuchsia.googlesource.com/third_party/mesa/+/main/src/intel/ vulkan/anv_magma.c * Access data and manifest files from manifest file system FD: The Fuchsia Vulkan loader service provides manifests using a service-provided virtual file system. It creates these filesystems based on the contents of multiple ICD packages and services it receives through devfs. As a result, they must be constructed using a filesystem serving library and don't reflect anything on-disk (see https://fuchsia.dev/fuchsia-src/contribute/governance/ rfcs/0205_vulkan_loader#filesystem_serving for details). The service-provided file system can be only opened as an FD using Fuchsia's FDIO (https://fuchsia.googlesource.com/fuchsia/+/main/sdk/ lib/fdio) library. Thus, in order to read manifest files located in a directory opened as an FD, we need to add a `parent_dir_fd` param to the functions that read files, including `loader_get_json` and `add_data_files`. * Migrated to the C++ FIDL bindings. The old C bindings are not supported anymore and have been deleted from the Fuchsia tree. This change migrates `dlopen_fuchsia` to use the C++ wire bindings (https://fuchsia.dev/fuchsia-src/reference/ fidl/bindings/cpp-bindings) which is part of the Fuchsia SDK. Test: libvulkan builds on Fuchsia with the changes above. Bug: https://fxbug.dev/378964821 Change-Id: I2af9f677d706d07193aecd2dcc4640ec602b138f
gnoliyil
added a commit
to gnoliyil/Vulkan-Loader
that referenced
this pull request
Feb 19, 2025
This change merges the Fuchsia-forked Vulkan-Loader branch into the upstream. Since last update (KhronosGroup#478), there has been significant changes to the way for Vulkan Loader to get manifests and the way for Vulkan ICDs to get I/O access to GPU devices. Also, Fuchsia has completely dropped C bindings for the FIDL API which `dlopen_fuchsia.c` uses. This change makes the following changes: * Add `loader_extensions_fuchsia.{cc,h}`. This allows the Vulkan Loader to provide a way to allow I/O to GPU devices to the ICDs it opens. The extended ICD API is defined in https://fuchsia.dev/fuchsia-src/ contribute/governance/rfcs/0205_vulkan_loader and it's implemented on ICDs like Fuchsia's Intel Mesa ICD: https://fuchsia.googlesource.com/third_party/mesa/+/main/src/intel/ vulkan/anv_magma.c * Access data and manifest files from manifest file system FD: The Fuchsia Vulkan loader service provides manifests using a service-provided virtual file system. It creates these filesystems based on the contents of multiple ICD packages and services it receives through devfs. As a result, they must be constructed using a filesystem serving library and don't reflect anything on-disk (see https://fuchsia.dev/fuchsia-src/contribute/governance/ rfcs/0205_vulkan_loader#filesystem_serving for details). The service-provided file system can be only opened as an FD using Fuchsia's FDIO (https://fuchsia.googlesource.com/fuchsia/+/main/sdk/ lib/fdio) library. Thus, in order to read manifest files located in a directory opened as an FD, we need to add a `parent_dir_fd` param to the functions that read files, including `loader_get_json` and `add_data_files`. * Migrated to the C++ FIDL bindings. The old C bindings are not supported anymore and have been deleted from the Fuchsia tree. This change migrates `dlopen_fuchsia` to use the C++ wire bindings (https://fuchsia.dev/fuchsia-src/reference/ fidl/bindings/cpp-bindings) which is part of the Fuchsia SDK. Test: libvulkan builds on Fuchsia with the changes above. Bug: https://fxbug.dev/378964821 Change-Id: I2af9f677d706d07193aecd2dcc4640ec602b138f
gnoliyil
added a commit
to gnoliyil/Vulkan-Loader
that referenced
this pull request
Feb 19, 2025
This change merges the Fuchsia-forked Vulkan-Loader branch into the upstream. Since last update (KhronosGroup#478), there has been significant changes to the way for Vulkan Loader to get manifests and the way for Vulkan ICDs to get I/O access to GPU devices. Also, Fuchsia has completely dropped C bindings for the FIDL API which `dlopen_fuchsia.c` uses. This change makes the following changes: * Add `loader_extensions_fuchsia.{cc,h}`. This allows the Vulkan Loader to provide a way to allow I/O to GPU devices to the ICDs it opens. The extended ICD API is defined in https://fuchsia.dev/fuchsia-src/ contribute/governance/rfcs/0205_vulkan_loader and it's implemented on ICDs like Fuchsia's Intel Mesa ICD: https://fuchsia.googlesource.com/third_party/mesa/+/main/src/intel/ vulkan/anv_magma.c * Access data and manifest files from manifest file system FD: The Fuchsia Vulkan loader service provides manifests using a service-provided virtual file system. It creates these filesystems based on the contents of multiple ICD packages and services it receives through devfs. As a result, they must be constructed using a filesystem serving library and don't reflect anything on-disk (see https://fuchsia.dev/fuchsia-src/contribute/governance/ rfcs/0205_vulkan_loader#filesystem_serving for details). The service-provided file system can be only opened as an FD using Fuchsia's FDIO (https://fuchsia.googlesource.com/fuchsia/+/main/sdk/ lib/fdio) library. Thus, in order to read manifest files located in a directory opened as an FD, we need to add a `parent_dir_fd` param to the functions that read files, including `loader_get_json` and `add_data_files`. * Migrated to the C++ FIDL bindings. The old C bindings are not supported anymore and have been deleted from the Fuchsia tree. This change migrates `dlopen_fuchsia` to use the C++ wire bindings (https://fuchsia.dev/fuchsia-src/reference/ fidl/bindings/cpp-bindings) which is part of the Fuchsia SDK. Test: libvulkan builds on Fuchsia with the changes above. Bug: https://fxbug.dev/378964821 Change-Id: I2af9f677d706d07193aecd2dcc4640ec602b138f
gnoliyil
added a commit
to gnoliyil/Vulkan-Loader
that referenced
this pull request
Feb 19, 2025
This change merges the Fuchsia-forked Vulkan-Loader branch into the upstream. Since last update (KhronosGroup#478), there has been significant changes to the way for Vulkan Loader to get manifests and the way for Vulkan ICDs to get I/O access to GPU devices. Also, Fuchsia has completely dropped C bindings for the FIDL API which `dlopen_fuchsia.c` uses. This change makes the following changes: * Add `loader_extensions_fuchsia.{cc,h}`. This allows the Vulkan Loader to provide a way to allow I/O to GPU devices to the ICDs it opens. The extended ICD API is defined in https://fuchsia.dev/fuchsia-src/ contribute/governance/rfcs/0205_vulkan_loader and it's implemented on ICDs like Fuchsia's Intel Mesa ICD: https://fuchsia.googlesource.com/third_party/mesa/+/main/src/intel/ vulkan/anv_magma.c * Access data and manifest files from manifest file system FD: The Fuchsia Vulkan loader service provides manifests using a service-provided virtual file system. It creates these filesystems based on the contents of multiple ICD packages and services it receives through devfs. As a result, they must be constructed using a filesystem serving library and don't reflect anything on-disk (see https://fuchsia.dev/fuchsia-src/contribute/governance/ rfcs/0205_vulkan_loader#filesystem_serving for details). The service-provided file system can be only opened as an FD using Fuchsia's FDIO (https://fuchsia.googlesource.com/fuchsia/+/main/sdk/ lib/fdio) library. Thus, in order to read manifest files located in a directory opened as an FD, we need to add a `parent_dir_fd` param to the functions that read files, including `loader_get_json` and `add_data_files`. * Migrated to the C++ FIDL bindings. The old C bindings are not supported anymore and have been deleted from the Fuchsia tree. This change migrates `dlopen_fuchsia` to use the C++ wire bindings (https://fuchsia.dev/fuchsia-src/reference/ fidl/bindings/cpp-bindings) which is part of the Fuchsia SDK. Test: libvulkan builds on Fuchsia with the changes above. Bug: https://fxbug.dev/378964821 Change-Id: I2af9f677d706d07193aecd2dcc4640ec602b138f
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fuchsia (fuchsia.dev) builds with GN and uses a loader service to load
the ICD into the application's address space.