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

Linking Errors. #493

Closed
ZKing1000 opened this issue Feb 11, 2020 · 23 comments
Closed

Linking Errors. #493

ZKing1000 opened this issue Feb 11, 2020 · 23 comments
Labels
type: bug Something isn't working

Comments

@ZKing1000
Copy link

[ 33%] Linking C executable triangle /usr/bin/ld: CMakeFiles/triangle.dir/main.c.o: in function main':
/home/holden/Desktop/work/forks/wgpu/examples/triangle/main.c:260: undefined reference to wgpu_render_pass_set_pipeline' /usr/bin/ld: /home/holden/Desktop/work/forks/wgpu/examples/triangle/main.c:261: undefined reference to wgpu_render_pass_set_bind_group'
/usr/bin/ld: /home/holden/Desktop/work/forks/wgpu/examples/triangle/main.c:262: undefined reference to wgpu_render_pass_draw' collect2: error: ld returned 1 exit status make[3]: *** [CMakeFiles/triangle.dir/build.make:101: triangle] Error 1 make[3]: Leaving directory '/run/media/holden/45993E4516E8C2C4/Git/forks/wgpu/examples/triangle/build' make[2]: *** [CMakeFiles/Makefile2:76: CMakeFiles/triangle.dir/all] Error 2 make[2]: Leaving directory '/run/media/holden/45993E4516E8C2C4/Git/forks/wgpu/examples/triangle/build' make[1]: *** [Makefile:84: all] Error 2 make[1]: Leaving directory '/run/media/holden/45993E4516E8C2C4/Git/forks/wgpu/examples/triangle/build' make: *** [Makefile:108: example-triangle] Error 2

@kvark kvark added the type: bug Something isn't working label Feb 12, 2020
@kvark
Copy link
Member

kvark commented Feb 12, 2020

Thank you for the report!
I was seeing this as well on Linux, although for the past weeks (months?) there was always more important things to address, so I didn't investigate.
A brief look at the symbols shows that they are there. Also, this works on macOS.
Any help in investigating this would be great!

@kvark
Copy link
Member

kvark commented Feb 12, 2020

I double-checked it now, and I was wrong - the symbols are totally missing:

kvark@ant /hub/moz/wgpu/examples/compute/build $ objdump -t /hub/moz/wgpu/target/debug/libwgpu_native.so | grep pass_dispatch
kvark@ant /hub/moz/wgpu/examples/compute/build $ objdump -t /hub/moz/wgpu/target/debug/libwgpu_native.so | grep set_pipeline

@kvark
Copy link
Member

kvark commented Feb 12, 2020

And here they are fully exposed by wgpu-core:

    #[no_mangle]
    pub unsafe extern "C" fn wgpu_compute_pass_set_pipeline(
        pass: &mut RawPass,
        pipeline_id: id::ComputePipelineId,
    ) {
        pass.encode(&ComputeCommand::SetPipeline(pipeline_id));
    }

So what might be happening is that the linker doesn't realize that C functions from dependent crates (going from wgpu-native) also need to be exposed?

@ZKing1000
Copy link
Author

Here is the Preceding Output:
1.txt

@ZKing1000
Copy link
Author

Possibly relevant:
rust-lang/rust#10025
rust-lang/rust#61820

@ZKing1000
Copy link
Author

github.com/mozilla/cbindgen/issues/49

@kvark
Copy link
Member

kvark commented Feb 12, 2020

@ZKing1000 thanks for the links!

It appears that we are able to work around this issue by adding #[linkage = "external"]

It's annoying and strange that we'd need to put it on each and every function.

Edit: it doesn't work:

error[E0658]: the linkage attribute is experimental and not portable across platforms

@ZKing1000
Copy link
Author

I'm not very Familiar with Rust, but I can try to help..

@CryZe
Copy link

CryZe commented Feb 12, 2020

This is the same issue as this then right? rust-lang/rust#50007

@ZKing1000
Copy link
Author

Looks like it.

@ZKing1000
Copy link
Author

rust-lang/rust#29603
https://github.com/thomcc/megazord/tree/simple-bug-repro

help: add #![feature(linkage)] to the crate attributes to enable

@ZKing1000
Copy link
Author

This looks like the commit that makes it not work: rust-lang/rust@7376ddb

@ZKing1000
Copy link
Author

I think I fixed... The symbols are present in libwgpu_native.a, but not .so.

examples/triangle/build/CMakeCache.txt:WGPU_LIBRARY:FILEPATH=/home/holden/Desktop/work/forks/wgpu/target/debug/libwgpu_native.a FROM .so

but now there are issues with libm (math library)

@ZKing1000
Copy link
Author

Built it:
cd examples/triangle
gcc -lglfw -lm -ldl -pthread -I../../ffi -I../../examples main.c framework.c libwgpu_native.a -o main

backtrace.txt

@ZKing1000
Copy link
Author

ZKing1000 commented Feb 15, 2020

I compiled this binary on Manjaro Linux with the -g flag.
Use GDB to run and debug.
https://drive.google.com/file/d/10yWzj4Mz4p2wFuu1Aoye3DJ4RtnoN-oE/view?usp=sharing

Edit: Compute Example compiles and runs fine.

@elgunhuseynli
Copy link

Same on Windows. I dump exports in .lib file, they are exported but with undersocre prefix.

Dump of file C:\Users\elgun\Desktop\wgpu\target\release\wgpu_native.dll.lib

File Type: LIBRARY

     Exports

       ordinal    name

                  _rust_eh_personality
                  _wgpu_adapter_destroy
                  _wgpu_adapter_request_device
                  _wgpu_bind_group_destroy
                  _wgpu_buffer_destroy
                  _wgpu_buffer_map_read_async
                  _wgpu_buffer_map_write_async
                  _wgpu_buffer_unmap
                  _wgpu_command_buffer_destroy
                  _wgpu_command_encoder_begin_compute_pass
                  _wgpu_command_encoder_begin_render_pass
...

@kvark
Copy link
Member

kvark commented Feb 19, 2020

@elgunhuseynli this looks like a different issue. Underscores could very well be expected there - a subject of calling convention. The original problem with linking was about routines exported from wgpu-core only, while your list has stuff from wgpu-native.

@kvark kvark added this to the Version 0.5 milestone Feb 19, 2020
@elgunhuseynli
Copy link

elgunhuseynli commented Feb 20, 2020

@kvark If underscores are expected why I'm getting unresolved external symbol error in Visual Studio? Maybe am I doing something wrong? :/

@kvark
Copy link
Member

kvark commented Feb 20, 2020

@elgunhuseynli are you seeing the same symbols unresolved as the original issue? If not, let's have a separate one.

@elgunhuseynli
Copy link

@kvark I get unresolved external symbol errors for all symbols even for wgpu_request_adapter_async

@kvark
Copy link
Member

kvark commented Feb 20, 2020

@elgunhuseynli please file another issue, it looks like nothing links for you at all.

@kvark kvark removed this from the Version 0.5 milestone Mar 28, 2020
@kvark
Copy link
Member

kvark commented Mar 28, 2020

Going to remove that from blockers for the release. First, because Rust users aren't affected. And second, because all is good as long as we provide the binary builds.

@cwfitzgerald
Copy link
Member

Seems this issue is external to us. If there is another issue, feel free to re-file.

kvark pushed a commit to kvark/wgpu that referenced this issue Jun 3, 2021
493: Use BCn textures if possible in skybox example r=kvark a=cwfitzgerald

This converts the skybox to using compressed textures if available. I have designed the code to be extensible to other compressed formats as they are added.

Additionally I added srgb to the texture types, as we were using a srgb framebuffer without properly converting into  linear on the texture reads.

Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants