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

gcc: always set the random seed for gcc builds #37

Merged
merged 1 commit into from
Jan 24, 2019
Merged

Conversation

terpstra
Copy link
Collaborator

Fixes #36

@richardxia
Copy link
Member

According to this comment on a random public GitHub ticket, the gcc man page says this about that flag:

-frandom-seed=string
 This option provides a seed that GCC uses when it would otherwise
 use random numbers. It is used to generate certain symbol names
 that have to be different in every compiled file.  It is also used
 to place unique stamps in coverage data files and the object files
 that produce them. You can use the -frandom-seed option to produce
 reproducibly identical object files.

 The string should be different for every file you compile.

I'm wondering if setting it to a globally constant value may cause issues with compiling certain projects.

This guide on reproducible builds suggests passing in the file name to get a deterministic seed that is at least different for each file.

@terpstra
Copy link
Collaborator Author

@richardxia I guess i'll use the workspace-unique file name for the seed. Even that's not bullet-proof because if you build a library, I could imagine someone else linking that library into a build in their own workspace with the same object file name.

However, all the ideas I could come up with to make the seed more unique have other problems. If you hash the file contents, then even irrelevant changes turn into object file changes which cascade into requiring downstream rebuild. There might be no reliable git hash available. You don't want to use anything timestamp/host-specific or the result can't be share-cached. So, unless, someone has a better idea, I guess this will have to do.

@terpstra terpstra merged commit d65e515 into master Jan 24, 2019
@terpstra terpstra deleted the random-seed branch January 24, 2019 04:48
@jackkoenig
Copy link
Contributor

From Richard's link:

When Link-Time Optimizations are turned on, GCC users will write random identifiers to binary objects they create.

Perhaps we should just turn off link-time optimizations? I think the risk of things going wrong is low, but any application that needs the benefits of LTO is probably going to to have their own build rules anyway

@terpstra
Copy link
Collaborator Author

Per my discussion with @jim-wilson, that is only one of the causes for gcc to need a PRNG. It can use it in other cases too.

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.

None yet

3 participants