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

darwin: Building with CGO produces warning #1660

Open
bwplotka opened this issue Oct 22, 2024 · 2 comments
Open

darwin: Building with CGO produces warning #1660

bwplotka opened this issue Oct 22, 2024 · 2 comments

Comments

@bwplotka
Copy link
Member

# github.com/prometheus/client_golang/prometheus
In file included from process_collector_cgo_darwin.c:21:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/shared_memory_server.h:48:2: warning: "<mach/shared_memory_server.h> is deprecated.  Please use <mach/shared_region.h> instead." [-W#warnings]

This is on the latest client_golang (main) version, likely after #1616

Does not look serious, but something to fix cc @mharbison72

@bwplotka
Copy link
Member Author

bwplotka commented Oct 22, 2024

This is a bit annoying because everyone who develops on Mac on binaries that import client_golang have this warning (by default e.g. on Goland CGO is enabled) 🤔 e.g. when running tests.

@mharbison72
Copy link
Contributor

Unfortunately, they don't provide a replacement header with a couple of constants that are used, and I'm not aware of any #pragma style directives that can be put into the code to suppress a #warning. The Apple repos have now been updated with the new OS release from last month, and nothing has changed in this area. That leaves us with a couple of hacky options:

  1. Copy the constants from the header, and don't include the header itself
  2. See if there's some CFLAGS option to suppress #warning directives
  3. Drop the adjustment of the value that's being done

The first is probably the easiest, and probably my preference (and add a #warning if the architecture isn't supported, since the constants are arch specific?).

The second seems too broad.

The third is a possibility, because as mentioned in the commit comment and the code, I've never seen the adjustment amount be non-zero. But if there's a case that could happen, we wouldn't report the same value as ps(1).

What do you think?

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

No branches or pull requests

2 participants