Skip to content
This repository has been archived by the owner on Jul 19, 2018. It is now read-only.

Fails to build with musl libc #1538

Closed
jku opened this issue Mar 8, 2017 · 3 comments
Closed

Fails to build with musl libc #1538

jku opened this issue Mar 8, 2017 · 3 comments
Assignees

Comments

@jku
Copy link

jku commented Mar 8, 2017

| ../loader/libvulkan.so.1.0.39: undefined reference to '__secure_getenv'

musl libc does not provide secure_getenv() or __secure_getenv() so linking the loader fails.

Would you accept a patch that uses getenv() instead in this case?

@MarkY-LunarG MarkY-LunarG self-assigned this Mar 8, 2017
@MarkY-LunarG
Copy link
Contributor

I've pushed commit f7a2742 up. Can you verify if that fixes the issue for you?

jku pushed a commit to jku/Vulkan-LoaderAndValidationLayers that referenced this issue Mar 9, 2017
__GNUC__ depends on the compiler, not libc so the check is broken.
It's also better to check for features, not libc versions.

Fixes KhronosGroup#1538.
jku pushed a commit to jku/Vulkan-LoaderAndValidationLayers that referenced this issue Mar 9, 2017
__GNUC__ depends on the compiler not libc, but here we are actually
interested in libc: current code ends up using getenv() when compiler
is not gcc.

Also, it's better to check for features anyway instead of libc's and
their versions.

Fixes KhronosGroup#1538.
@jku
Copy link
Author

jku commented Mar 9, 2017

I've made a PR on top of current master: the current code mistakenly checks for __GNUC__ when the original author probably wanted __GLIBC__. My fix doesn't do that either though as checking for features is just better.

My musl build is not running master but I verified a backported version: works with musl and modern glibc.

@MarkY-LunarG
Copy link
Contributor

This should now be fixed, so closing issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants