Truffleruby: Error installing hitimes v 1.3.0 under 1.0.0-rc7

[jjyr]

Installing hitimes 1.3.0 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/ruby/gems/2.4.0/gems/hitimes-1.3.0/ext/hitimes/c
/Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/bin/truffleruby -r ./siteconf20181017-93111-1gqwlda.rb extconf.rb
creating Makefile

current directory: /Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/ruby/gems/2.4.0/gems/hitimes-1.3.0/ext/hitimes/c
make "DESTDIR=" clean

current directory: /Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/ruby/gems/2.4.0/gems/hitimes-1.3.0/ext/hitimes/c
make "DESTDIR="
compiling hitimes.c
compiling hitimes_instant_clock_gettime.c
compiling hitimes_instant_osx.c
compiling hitimes_instant_windows.c
compiling hitimes_interval.c
compiling hitimes_stats.c
linking shared-object hitimes/2.4/hitimes.su
/Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/cext/linker.rb:67:in `process_args': Unknown argument: -framework
(RuntimeError)
    from /Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/cext/linker.rb:21:in `main'
    from /Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/cext/linker.rb:150:in `<main>'
make: *** [hitimes.su] Error 1

make failed, exit code 2

Gem files will remain installed in /Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/ruby/gems/2.4.0/gems/hitimes-1.3.0 for
inspection.
Results logged to
/Users/jiangjinyang/.rbenv/versions/truffleruby-1.0.0-rc7/lib/ruby/gems/2.4.0/extensions/x86_64-darwin/2.4.0/hitimes-1.3.0/gem_make.out

An error occurred while installing hitimes (1.3.0), and Bundler cannot continue.
Make sure that `gem install hitimes -v '1.3.0' --source 'https://rubygems.org/'` succeeds before bundling.

In Gemfile:
  ciri was resolved to 0.0.4, which depends on
    async-io was resolved to 1.15.5, which depends on
      async was resolved to 1.10.3, which depends on
        timers was resolved to 4.1.2, which depends on
          hitimes

[chrisseaton]

Thanks for the report. I believe this is probably happening because we have a custom linker that does not yet support all arguments, but we can fix this. We'll look into it.

[eregon]

Just as a note, I think nowadays using the standard Process.clock_gettime method (since Ruby 2.1) is a good replacement for hitimes which mostly exposes similar fonctionality when the core method did not exist yet.
So it might be worth to raise an issue to the timers gem to use Process.clock_gettime unless they want to support older Ruby versions than 2.1.

Nevertheless, it would be good to support the -framework linking argument in TruffleRuby, but hitimes adds a fair bit of complexity compared to a standard Ruby API in this case.

[deepj]

@eregon hitimes is one of sub-depecencies of falcon (high-performance web server for Ruby). This is the reason why @jjyr is trying it. It will be very interesting to see performance of falcon under truffleruby.

[chrisseaton]

Is Falcon Ruby all the way down? I see there is what appears to be a pure Ruby implementation of HTTP and even HTTP 2?

[deepj]

@chrisseaton yes, it'd be all in pure Ruby except the dependency on hitimes in timers required by async. Everything is from the same author @ioquatix

$ gem install falcon
Fetching: http-hpack-0.1.1.gem (100%)
Successfully installed http-hpack-0.1.1
Fetching: http-protocol-0.9.2.gem (100%)
Successfully installed http-protocol-0.9.2
Fetching: hitimes-1.3.0.gem (100%)
Building native extensions. This could take a while...
Successfully installed hitimes-1.3.0
Fetching: timers-4.1.2.gem (100%)
Successfully installed timers-4.1.2
Fetching: async-1.10.3.gem (100%)
Successfully installed async-1.10.3
Fetching: async-io-1.16.3.gem (100%)
Successfully installed async-io-1.16.3
Fetching: async-http-0.37.0.gem (100%)
Successfully installed async-http-0.37.0
Fetching: async-container-0.8.1.gem (100%)
Successfully installed async-container-0.8.1
Fetching: mapping-1.1.1.gem (100%)
Successfully installed mapping-1.1.1
Fetching: samovar-1.9.1.gem (100%)
Successfully installed samovar-1.9.1
Fetching: localhost-1.1.4.gem (100%)
Successfully installed localhost-1.1.4
Fetching: falcon-0.19.2.gem (100%)
Successfully installed falcon-0.19.2
12 gems installed

[eregon]

@deepj @ioquatix Seems an even bigger reason to avoid the dependency on hitimes (then it would be pure Ruby), but I guess necessary if Ruby 2.0 is supported by async or timers.

Anyway, we should look at supporting hitimes.
Note that hitimes installs fine on Linux, it's only an issue on macOS due to this -framework linker argument.
@chrisseaton @aardvark179 Any idea how to handle -framework?

[ioquatix]

hitimes could probably be removed.

[ioquatix]

Hold on I'm just getting my coffee...

[ioquatix]

Okay, I have it working locally.

[ioquatix]

Okay, I released v4.2.0 which doesn't depend on hitimes. Can you let me know if this helps?

[eregon]

@ioquatix Thank you! It seems to work fine, I tried gem install timers on Linux, and it doesn't try to install hitimes anymore.
Installing falcon also works on Linux BTW.

[ioquatix]

@eregon That is so exciting!!

Just ping me up when you hit the next roadblock. This is awesome.

[ioquatix]

While the original issue may still be a problem, the need to install hitimes has been resolved, so I think we can close this issue @jjyr

[jjyr]

I'd rather leave to truffleruby devs to close this since this issue maybe affect other gems. @ioquatix

[eregon]

Let's close this as the original report works now, and Process.clock_gettime is a good replacement.
If anyone hits the problem again due to another dependency on hitimes, please reopen or comment here.

[deepj]

@eregon Isn't this issue more about the unsupported -framework linking argument rather than about hitimes itself?

[eregon]

@deepj I'd rather focus on issues with a practical problem. If -framework is a problem for installing some dependency, then we should fix it, but I'd rather not prioritize it until there is a good need for it.

BTW, recent macOS also has clock_gettime, so this framework argument shouldn't be needed on recent macOS versions. And of course, hitimes could likely just use Process.clock_gettime and avoid the C extension entirely.

[eregon]

I opened an issue on the hitimes tracker to consider using Process.clock_gettime as a backend:
https://github.com/copiousfreetime/hitimes/issues/72

[copiousfreetime]

I need to confirm a few things - but initially looks doable to move hitimes to pure ruby.

[eregon]

@copiousfreetime Great to hear :)

[shayneoneill]

was a solution ever found for how to install this? I havent worked out which of my Gemfile dependencies want this as I'm not asking for it explicitely, but its barfing on the same linker problem.

I think its socketry thats causing the dependency

[eregon]

@shayneoneill I'm working on a general solution to use the native linker, which should address this.

In the Gemfile.lock it should be relatively clear what depends on hitimes.

[shayneoneill]

Yeah I think it was socketry that was causing it. I forked socketry and just removed the dep from its manifest and it all installed fine. As for it working... well thats a different tale for a different time!