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

[Issue] Bicep installer prefers MUSL variant over glibc #2683

Closed
mthebridge opened this issue Aug 31, 2023 · 4 comments · Fixed by #2722
Closed

[Issue] Bicep installer prefers MUSL variant over glibc #2683

mthebridge opened this issue Aug 31, 2023 · 4 comments · Fixed by #2722
Assignees

Comments

@mthebridge
Copy link

Output from azd version
azd version 1.2.0 (commit 99ea757)

Describe the bug
When azd installs its bicep provider, it uses the presence of the MUSL linker on the system to determine whether to install a MUSL based bicep. See this code here:

if _, err := os.Stat("/lib/ld-musl-x86_64.so.1"); err == nil {

I believe this is the same issue in the main Azure CLI as Azure/bicep#5040 which was fixed by only installing the musl-based variant if there is no glibc installed. Could the same fix as made under https://github.com/Azure/azure-cli/pull/23040/files be made here in the developer CLI? Happy to offer a PR if that would be helpful.

To Reproduce

  • Install the musl libc toolchain.
  • Run azd up in a Bicep-based deployment. Bicep installs but fails to run.

Expected behavior

Bicep should be installed for the correct system libc.

Environment
WSL Ubuntu 20.04 on Windows 11.

@rajeshkamal5050
Copy link

@ellismg can you take a look at @mthebridge recommendation?

ellismg added a commit to ellismg/azure-dev that referenced this issue Sep 7, 2023
This matches the behavior of the `az` CLI, which uses this same
logic. When we orginally implemented this, `az` did not have this
special case, it was added later.

Fixes Azure#2683
@ellismg
Copy link
Member

ellismg commented Sep 7, 2023

Thought that I wrote a response here but looks like I forgot to submit it. Thanks for opening this @mthebridge. You are correct that we modeled getting bicep off the logic in the az CLI. When we added it, they had not yet landed that fix, so we didn't pick it up. I opened a PR that adds this to our heuristic. Thanks for pointing it out, @mthebridge!

@ellismg
Copy link
Member

ellismg commented Sep 7, 2023

FWIW, as a workaround until the fix lands (or for others who stumble upon this issue later) you can download the glibc bicep yourself from the GitHub releases page and then set the environment variable AZD_BICEP_TOOL_PATH to the full path to the bicep you downloaded. In that case, we will use that version instead of the one that azd downloads and manages itself.

@mthebridge
Copy link
Author

FWIW, as a workaround until the fix lands (or for others who stumble upon this issue later) you can download the glibc bicep yourself from the GitHub releases page and then set the environment variable AZD_BICEP_TOOL_PATH to the full path to the bicep you downloaded. In that case, we will use that version instead of the one that azd downloads and manages itself.

Thanks @ellismg - I'd already discovered that workaround and have been using that fine.

ellismg added a commit that referenced this issue Sep 8, 2023
This matches the behavior of the `az` CLI, which uses this same
logic. When we orginally implemented this, `az` did not have this
special case, it was added later.

Fixes #2683
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants