Bug #14165: 61096 - support 128bit ino on Windows (if available) - MinGW Problems - compile & fiddle / libffi

• Status: Closed
• Assignee: usa (Usaku NAKAMURA)
• Target version: -
• ruby -v: ruby 2.5.0dev (2017-12-11 trunk 61097) [x64-mingw32]
• Backport: 2.3: DONTNEED, 2.4: DONTNEED

[MSP-Greg (Greg L)]

Last ruby-loco build has warnings & test failures after 61097. Build log (attached) has 329 instances of:

include/ruby/win32.h:197:0: warning: "SIZEOF_STRUCT_STAT_ST_INO" redefined

Same issue with test failures (attached as 61097_test-all_issues.log)

Thanks, Greg

[MSP-Greg (Greg L)]

• Subject changed from 61097 - support 128bit ino on Windows (if available) - MinGW Problems to 61096 - support 128bit ino on Windows (if available) - MinGW Problems - compile & fiddle / libffi
• ruby -v set to ruby 2.5.0dev (2017-12-11 trunk 61097) [x64-mingw32]

Did a vc140 build, all okay as far as 61096/61097.

Checked again on the MinGW build, and the issue above exists, but also noticed that the MinGW libffi package is now no longer found, and hence, fiddle is not built. But, it's finding the gdbm, openssl, and zlib packages as before...

As this is a rolling build, it built several times on Appveyor with 61095, and there were no issues.

EDIT: svn 61108 just built on Appveyor, it failed also.

Thanks, Greg

[kubo (Takehiro Kubo)]

• File sizeof_st_ino_on_mingw32.patch sizeof_st_ino_on_mingw32.patch added

How about the attached patch?
It doesn't define SIZEOF_STRUCT_STAT_ST_INO in include/x64-mingw32/ruby/config.h if target_os is mingw32.

Apply the patch and create configure by autoconf.
Sorry, I have not tested it.

[MSP-Greg (Greg L)]

@kubo (Takehiro Kubo),

Thank you for the patch. That does allow MinGW to build. I'll add it to ruby-loco.

Both my system, ruby-loco, and Lars Kanis' RubyInstaller2 use MSYS2/MinGW. The current gcc version in that system is 7.2.0. I've gotten the impression that the warning/error settings for it are set 'tighter' than many of the other compilers currently used for Ruby.

Two questions:

1. Is this a MinGW issue, or an issue with gcc 'rejecting' the code?

2. The patch appears to avoid the new (and better?) definition if it's a MinGW build, but the definition seems to work with both vc120 and vc140 builds. Is it possible to adjust the code avoid the double definition, rather than disallowing it? I don't know if this feature is OS version dependent, but I thought some of the recent file time patches did make use of OS versioning in their defs...

Reminder, I'm not a c type, so please forgive me if this is totally wrong. Thanks again for the patch, Greg

[usa (Usaku NAKAMURA)]

• Status changed from Open to Closed

Applied in changeset trunk|r61119.

---

undef previous definition of SIZEOF_STRUCT_STAT_ST_INO

trying to solve build problem of MinGW. see [Bug #14165]

[usa (Usaku NAKAMURA)]

• Status changed from Closed to Assigned
• Assignee set to usa (Usaku NAKAMURA)

hmm, SIZEOF_STRUCT_STAT_ST_INO is defined in ruby.h, so I expects that it's also defined in MinGW build.
And I do not understand why changes in Ruby affect to build libffi.
Greg, could you check r61119?

[MSP-Greg (Greg L)]

Usaka,

And I do not understand why changes in Ruby affect to build libffi.

I noticed that RubyGems fails on compile warnings. Does mkmf.rb do the same? The fiddle mkmf.log did have warnings in it (a local build).

I was just about to make a separate issue. I'm all for making use of new Windows functionality, but...

I thought the some of the new file time functions are OS version dependent. I don't recall if they're compile time or runtime.

Up to this point windows builds have been OS version independent (build anywhere, use anywhere), and I suspect they're compatible with at least Vista forward, maybe Win7.

Also, I don't recall seeing any of the test-all or spec tests being version dependent. I certainly prefer that (for the time being) Ruby could continue to be built on any compatible version of Windows and the transferred and used on any other compatible version. Likewise, any tests/specs should work, regardless of build OS version or test site version.

Any thoughts? Thanks, Greg

[jeremyevans0 (Jeremy Evans)]

MSP-Greg (Greg L) wrote:

I noticed that RubyGems fails on compile warnings. Does mkmf.rb do the same? The fiddle mkmf.log did have warnings in it (a local build).

mkmf sets :werror => true by default, which I think is a mistake. I have a patch in #13069 that turns off :werror by default, though users can still set $werror = true if they want that behavior.

[MSP-Greg (Greg L)]

Thanks to Usaka & Kubo, all is okay with the ruby-loco MinGW build as of 61121.

Okay to close... Greg

[usa (Usaku NAKAMURA)]

• Status changed from Assigned to Closed
• Backport changed from 2.3: UNKNOWN, 2.4: UNKNOWN to 2.3: DONTNEED, 2.4: DONTNEED

Thank you for checking, Greg!