Skip to content

Conversation

@madsmtm
Copy link
Contributor

@madsmtm madsmtm commented Jan 27, 2025

When the user uses .cflag/.cxxflag/.asmflag, we want those flags to take precedence over the default flags that cc-rs adds.

@madsmtm madsmtm force-pushed the user-specified-takes-precedence branch from 056a6ea to 4e9ce56 Compare January 27, 2025 01:25
@madsmtm
Copy link
Contributor Author

madsmtm commented Jan 27, 2025

The nightly error is rust-lang/rust#136086, will be fixed by rust-lang/rust#136098.

@jyn514
Copy link
Member

jyn514 commented Jan 27, 2025

for posterity, the full error was

   Compiling test-crate v0.1.0 (/Users/runner/work/cmake-rs/cmake-rs/test-crate)
error: linker stderr: ld: search path '/Users/runner/work/cmake-rs/cmake-rs/test-crate/target/debug/build/libz-sys-ae8c893dbe111c55/out/lib64' not found
       ld: object file (/Users/runner/work/cmake-rs/cmake-rs/test-crate/target/debug/deps/liblibz_sys-297f35bb33641431.rlib[31](zutil.c.o)) was built for newer 'macOS' version (14.5) than being linked (11.0)
  |
  = note: `-D linker-messages` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(linker_messages)]`

(CI logs go away after about 3 months)

@jyn514
Copy link
Member

jyn514 commented Jan 27, 2025

note that i do not plan to silence the "search path" not found error, so that will eventually come back unless someone makes a convincing case why it shouldn't.

@madsmtm madsmtm force-pushed the user-specified-takes-precedence branch from 4e9ce56 to 836acf7 Compare February 10, 2025 09:26
@madsmtm
Copy link
Contributor Author

madsmtm commented Feb 10, 2025

Rebased, and filed rust-lang/libz-sys#235 to avoid the libz-sys linker warning happening in the future.

@ChrisDenton
Copy link
Member

Hi! cmake-rs hasn't really been maintained in awhile but I'm trying to at least take a look at the open PRs.

What is this status of this PR? Is it still wanted/needed? Is there any more context I should be aware of?

@madsmtm
Copy link
Contributor Author

madsmtm commented Dec 13, 2025

I've kind of lost the context for this, but lemme try to recall: The flags that we import from cc-rs are partly meant to help us set up the "default" flags for a given target triple, and partly to allow the user to overwrite flags with environment variables.

This PR would make the ordering correct for the first case, but I think we'd still want environment variables like CFLAGS to override whatever is set in these methods, see e.g. the flag ordering in rust-lang/cc-rs#1403.

So the proper solution here is probably for cmake-rs to make .cflag call cc::Builder::flag, and then allow cc-rs to determine the order of flags at the end.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants