Bug #21995: mkmf generates a non-deterministic log file

• Status: Assigned
• Assignee: hsbt (Hiroshi SHIBATA)
• Target version: -
• ruby -v: ruby 4.1.0dev (2026-04-12T14:25:33Z master 6593cc52d6) +PRISM [x86_64-linux]
• Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN

[gemmaro (Gemma Kosaka)]

Hello,

When compiling Ruby's C extensions with mkmf, it can generate a mkmf.log file with non-deterministic content, especially at the line below:

ld: /tmp/rubytest.h8pay9/cc3fbuGm.o: in function `t':
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This can be problematic on some distributions/package-managers, since the mkmf.log file is included in the files generated by gem install.

example flowexample flow

Note about an example flow where randomized filenames occur:

1. extconf.rb has calls to have_func
2. gem install is run by the user
3. It invokes mkmf to process the extconf.rb file
4. The checks fail and print intermediate randomized filenames, which are recorded in mkmf.log file
5. gem install includes mkmf.log in the packaged files
6. When the gem is built/packaged multiple times, a reproducibility problem occurs

backgroundbackground

As a background, the previously reported/related issues are:

• Bug #15304: Package build with extensions is not reproducible

  • This mentions temporary filenames in the generated Makefile, and they are not reproducible.

  • The necessity/value of including Makefile, gem_make.out, and mkmf.log files are questioned.

  • So the pull request was created to omit these files when installing gems.

  • However, deleting these files might break compatibility, so the pull request was closed.

  • Note: There is an entry about mkmf.log in the RubyGems' changelog:

    2.2.2 / 2014-02-05

    Bug fixes:

    • [...]
    • The mkmf.log is now placed next to gem_make.out when building extensions.

• Bug #19329: "gem install" installs logs and other "noisy", non-reproducible files

  • This points out that gem install installs mkmf.log file.
  • It was transferred at RubyGems GitHub repository.

• There are some issues related to this topic on the GNU Guix channel

  • For example, when I was packaging Ruby 4.0 for Guix, this reproducibility problem occured.

• There should be other workarounds in the Nix community, apparently.

To wrap up, I think the followings are desirable:

• Conventional file locations should be kept as is on the RubyGems side.
  • Just deleting these files breaks compatibilities.
  • These might be helpful when users report issues to gem owners with detailed information.
• It is helpful if generated file contents are as reproducible as possible.
  • In some contexts where reproducibility matters, this issue makes packaging Ruby gems a bit harder.
  • Luckily, workarounds are possible in distribution package recipes such as deleting these files.
• -> the component that generates mkmf.log is mkmf, so it might be resolvable by modifying mkmf itself.

Thank you,
gemmaro.

[gemmaro (Gemma Kosaka)]

I created a pull request about this.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to hsbt (Hiroshi SHIBATA)

I will look this.

[gemmaro (Gemma Kosaka)]

Thanks for the reply! I'm sorry -- this pull request #note-1 currently fails CI, and I'm still investigating why. It's not ready for review yet, so it would be appreciated if you could revisit when it is.

[Hanmac (Hans Mackowiak)]

i think the main question is:

Why is mkmf.log file is included in the files generated by gem install?

Shouldn't it be okay to skip these files?
Especially for distributions/package-managers?

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Rejected

mkmf.log is not intended to be installed.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Rejected to Assigned

@gemmaro (Gemma Kosaka)

Could you clarify what you mean by "distributions/package-managers"? Also, do they actually include the RubyGems log files (like mkmf.log) in their packages?

[gemmaro (Gemma Kosaka)]

@hsbt (Hiroshi SHIBATA)

Could you clarify what you mean by "distributions/package-managers"?

"distributions/package-managers" in the issue description refers, broadly, to systems that allow software packages to cooperate -- automatically tracking dependencies, locating files, and managing environment variables -- while making them easily installable, upgradable, and removable. Here, however, I specifically mean systems with stricter reproducibility guarantees, such as the Guix or Nix package managers.

For those unfamiliar with such systems, these are conceptually similar to Bundler. For example, running guix shell ruby ruby-nokogiri drops you into a shell with Ruby and Nokogiri installed and the environment fully set up. The key difference is that these guarantee that installing the same package on the same architecture always produces bit-for-bit identical results.

Also, do they actually include the RubyGems log files (like mkmf.log) in their packages?

Yes, at least with Guix, some packages do include the log files.

results of guix locate commandresults of guix locate command

$ guix locate mkmf.log
ruby-json@2.1.0      /gnu/store/...-ruby-json-2.1.0/lib/ruby/vendor_ruby/extensions/x86_64-linux/3.3.0/json-2.1.0/mkmf.log
ruby-racc@1.5.2      /gnu/store/...-ruby-racc-1.5.2/lib/ruby/vendor_ruby/extensions/x86_64-linux/3.3.0/racc-1.5.2/mkmf.log
ruby-sqlite3@2.5.0   /gnu/store/...-ruby-sqlite3-2.5.0/lib/ruby/vendor_ruby/extensions/x86_64-linux/3.3.0/sqlite3-2.5.0/mkmf.log
ruby@3.3.9           /gnu/store/...-ruby-3.3.9/lib/ruby/gems/3.3.0/gems/rbs-3.4.0/ext/rbs_extension/mkmf.log
ruby@3.3.9           /gnu/store/...-ruby-3.3.9/lib/ruby/gems/3.3.0/gems/debug-1.9.2/ext/debug/mkmf.log
ruby@3.4.7           /gnu/store/...-ruby-3.4.7/lib/ruby/gems/3.4.0/gems/syslog-0.2.0/ext/syslog/mkmf.log
ruby@3.4.7           /gnu/store/...-ruby-3.4.7/lib/ruby/gems/3.4.0/gems/rbs-3.8.0/ext/rbs_extension/mkmf.log
ruby@3.4.7           /gnu/store/...-ruby-3.4.7/lib/ruby/gems/3.4.0/gems/nkf-0.2.0/ext/nkf/mkmf.log
ruby@3.4.7           /gnu/store/...-ruby-3.4.7/lib/ruby/gems/3.4.0/gems/debug-1.11.0/ext/debug/mkmf.log
ruby@3.4.6           /gnu/store/...-ruby-3.4.6/lib/ruby/gems/3.4.0/gems/syslog-0.2.0/ext/syslog/mkmf.log
ruby@3.4.6           /gnu/store/...-ruby-3.4.6/lib/ruby/gems/3.4.0/gems/rbs-3.8.0/ext/rbs_extension/mkmf.log
ruby@3.4.6           /gnu/store/...-ruby-3.4.6/lib/ruby/gems/3.4.0/gems/nkf-0.2.0/ext/nkf/mkmf.log
ruby@3.4.6           /gnu/store/...-ruby-3.4.6/lib/ruby/gems/3.4.0/gems/debug-1.11.0/ext/debug/mkmf.log

That said, as these files are increasingly being identified as a source of reproducibility check failures, existing packages may also start applying workarounds in their recipes, such as explicitly deleting these log files.

---

As I described in the issue, based on my research into the history of this topic, I had assumed that including log files such as mkmf.log in the files generated by gem install was intended behavior. That said, if gem install were changed to skip these files, I would consider that a step in the right direction (for reproducibility-aware package managers).