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.

Sign up for GitHub

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

Jump to bottom

rustpkg may be ignoring -O flag #10468

Closed
catamorphism opened this issue Nov 14, 2013 · 6 comments
Closed

rustpkg may be ignoring -O flag #10468

catamorphism opened this issue Nov 14, 2013 · 6 comments
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@catamorphism
Copy link
Contributor

@chrismorgan reports that rustpkg install -O http (after git cloneing http://github.com/chris-morgan/rust-http ) seems to silently ignore the -O flag. (I'm not yet sure whether this is because it should be rustpkg -O install http or not, as I haven't reproduced it yet. Of course, both ways should work.)
@chris-morgan
Copy link
Member

I'm getting the same results (viz. no optimisations) for -O before or after the subcommand and for both the install and build subcommands.

Here are rust-http sizes, for example:

  • rustc -O: 1244971
  • rustpkg (-O or not): 1710369 or 1710377, as measured (don't ask me, I'm just the messenger who ran rustpkg build http multiple times after cleaning and got different results)
  • rustc: 1710145 (why is this not bitwise identical to the rustpkg build?)

@catamorphism
Copy link
Contributor Author

On IRC, @huonw noted that even rustc itself doesn't always generate an identical binary for identical input. (Though that's tangential to the issue with the -O flag.)

@huonw
Copy link
Member

huonw commented Nov 14, 2013

(It just appears that the binary from crates without a #[link(name)] depends on the value of -o on Linux. That is, compiling multiple times with the same -o or adding the name attribute gives the same result each time.)

@catamorphism catamorphism mentioned this issue Nov 15, 2013
Closed
@itdaniher
Copy link
Contributor

In the meantime, you might try seeing if rustpkg --opt-level=3 build package yields different results, as a workaround.

No dice.

Anyone have other ideas for a workaround?

I've been continuing to poke around the rustpkg source, but I can't seem to build it without rebuilding the whole tree - rustpkg build librustpkg is a nogo.

@itdaniher itdaniher mentioned this issue Nov 17, 2013
Merged
bors added a commit that referenced this issue Nov 18, 2013
@bors
auto merge of #10526 : itdaniher/rust/master, r=pcwalton
727b70d 
This commit fixes issue #10468.

It propagate optimization level from PkgSrc to compile_crate as a rustc::driver::session::OptLevel enum.

The 'opt' argument to compile_crate was previously hardcoded as boolean false, such that calls to session::options would always result in the session::No flag being used.
@emberian
Copy link
Member

#10526 supposedly fixed, just needs a test.

@darnuria
Copy link
Contributor

Rustpkg was dropped... Transfers the bug to the actual repository of rustpkg and close it?

flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 24, 2023
@bors
Auto merge of rust-lang#10481 - blyxyas:allow_attribute, r=xFrednet
5afa93b 
Add `allow_attribute` lint

Fixes rust-lang#10468

changelog: new lint: [`allow_attributes`]
[rust-lang#10481](rust-lang/rust-clippy#10481)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@itdaniher @metajack @chris-morgan @catamorphism @emberian @huonw @darnuria