Skip to content

Fix compilation issues with libuv on OSX #8832

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

Closed
wants to merge 1 commit into from

Conversation

alexcrichton
Copy link
Member

It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.

This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"

Closes #8826

@lilyball
Copy link
Contributor

Seems to be working for me. Surprised @pcwalton didn't give it a higher priority since this is just a wee bit of an issue for anyone on 64-bit.

It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.

This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"

Closes rust-lang#8826
bors added a commit that referenced this pull request Aug 29, 2013
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.

This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"

Closes #8826
@bors bors closed this Aug 29, 2013
xFrednet pushed a commit to xFrednet/rust that referenced this pull request May 21, 2022
Add `duplicate_mod` lint

Inspired by rust-lang#8827, warns if there's a single file that is loaded by more than one `mod` item

```rust,ignore
// lib.rs
mod a;
mod b;
```
```rust,ignore
// a.rs
#[path = "./b.rs"]
mod b;
```

It adds a `canonicalize` call per `mod file;` encountered, which I don't think should be too heavy

Integration tests with common modules, e.g. [`test_utils`](https://github.com/rust-lang/rust-clippy/tree/2038084cf2253b57cf8b405ab000a92b68346f43/tests/test_utils) doesn't trigger it as each test is compiled separately, however I couldn't figure out a good way to add a test for that

changelog: Add [`duplicate_mod`] lint
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.

libuv has it's target_arch specified incorrectly
3 participants