Page 2 of 2

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Sun Mar 27, 2016 8:18 pm
by minicoin
Thanks. Happy Easter :-)

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Thu Mar 31, 2016 3:20 am
by minicoin
Two more errors. The first one seems to be a result of the RubyGem ffi (https://rubygems.org/gems/ffi):
Code: Select all
iPhoney:/usr/local/ruby/bin root# ./gem install jekyll
Building native extensions.  This could take a while…
ERROR:  Error installing jekyll:
        ERROR: Failed to build gem native extension.

    current directory: /usr/local/ruby/lib/ruby/gems/2.3.0/gems/ffi-1.9.10/ext/ffi_c
/usr/local/ruby/bin/ruby -r ./siteconf20160330-27096-13r41lb.rb extconf.rb
checking for ffi.h… *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        —with-opt-dir
        —without-opt-dir
        —with-opt-include
        —without-opt-include=${opt-dir}/include
        —with-opt-lib
        —without-opt-lib=${opt-dir}/lib
        —with-make-prog
        —without-make-prog
        —srcdir=.
        —curdir
        —ruby=/usr/local/ruby/bin/$(RUBY_BASE_NAME)
        —with-ffi_c-dir
        —without-ffi_c-dir
        —with-ffi_c-include
        —without-ffi_c-include=${ffi_c-dir}/include
        —with-ffi_c-lib
        —without-ffi_c-lib=${ffi_c-dir}/lib
        —with-libffi-config
        —without-libffi-config
        —with-pkg-config
        —without-pkg-config
/usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:456:in `try_do’: The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:587:in `try_cpp’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:1091:in `block in have_header’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:942:in `block in checking_for’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:350:in `block (2 levels) in postpone’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:320:in `open’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:350:in `block in postpone’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:320:in `open’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:346:in `postpone’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:941:in `checking_for’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:1090:in `have_header’
        from extconf.rb:16:in `<main>‘

To see why this extension failed to compile, please check the mkmf.log which can be found here:

  /usr/local/ruby/lib/ruby/gems/2.3.0/extensions/armv8-darwin-14/2.3.0-static/ffi-1.9.10/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in /usr/local/ruby/lib/ruby/gems/2.3.0/gems/ffi-1.9.10 for inspection.
Results logged to /usr/local/ruby/lib/ruby/gems/2.3.0/extensions/armv8-darwin-14/2.3.0-static/ffi-1.9.10/gem_make.out


The second error I get occurs when installing the gem rails:

Code: Select all
iPhoney:/usr/local/ruby/bin root# ./gem install rails
Building native extensions.  This could take a while…
ERROR:  Error installing rails:
        ERROR: Failed to build gem native extension.

    current directory: /usr/local/ruby/lib/ruby/gems/2.3.0/gems/nokogiri-1.6.7.2/ext/nokogiri
/usr/local/ruby/bin/ruby -r ./siteconf20160330-27108-1m8ias7.rb extconf.rb
checking if the C compiler accepts … *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        —with-opt-dir
        —without-opt-dir
        —with-opt-include
        —without-opt-include=${opt-dir}/include
        —with-opt-lib
        —without-opt-lib=${opt-dir}/lib
        —with-make-prog
        —without-make-prog
        —srcdir=.
        —curdir
        —ruby=/usr/local/ruby/bin/$(RUBY_BASE_NAME)
        —help
        —clean
/usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:456:in `try_do’: The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:571:in `block in try_compile’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:522:in `with_werror’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:571:in `try_compile’
        from extconf.rb:80:in `nokogiri_try_compile’
        from extconf.rb:87:in `block in add_cflags’
        from /usr/local/ruby/lib/ruby/2.3.0/mkmf.rb:629:in `with_cflags’
        from extconf.rb:86:in `add_cflags’
        from extconf.rb:336:in `<main>‘

To see why this extension failed to compile, please check the mkmf.log which can be found here:

  /usr/local/ruby/lib/ruby/gems/2.3.0/extensions/armv8-darwin-14/2.3.0-static/nokogiri-1.6.7.2/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in /usr/local/ruby/lib/ruby/gems/2.3.0/gems/nokogiri-1.6.7.2 for inspection.
Results logged to /usr/local/ruby/lib/ruby/gems/2.3.0/extensions/armv8-darwin-14/2.3.0-static/nokogiri-1.6.7.2/gem_make.out

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Tue Apr 05, 2016 3:05 am
by morpheus
You get both of these because "installing the gems" involves compiling them first - and there is no compiler on iOS (yet)

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Tue Apr 05, 2016 2:06 pm
by minicoin
Huh. That's a bummer.

Off-topic: saurik isn't going to accept those iOS binaries you provided. He says decades old GNU utilities are better than minutes old BSD ones... yeah, okay. Source: https://www.reddit.com/r/jailbreak/comments/4dd94p/discussion_if_the_next_jailbreak_didnt_include/d1q34bf

I just wish we weren't forced into GNU :/. saurik is using GNU exclusive arguments, like cp -T. Replacing the GNU version of cp with the BSD version ends up breaking Cydia's stashing script(s). Ugh. It doesn't help that saurik hasn't recompiled these utilities from 2009, either.

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Tue Apr 05, 2016 3:12 pm
by morpheus
Since I don't reddit, please quote me on that in reddit (or maybe link here?)

-- begin quote --

A) "Decades old" vs. "Minutes old" is wrong. The compiled utilities are from Darwin, which has been around *and used by AAPL* for at least the past 14 years. So I don't get that argument. Besides, people coming from OS X want the same experience - and that's why it makes sense to port the OS X utilities, rather than use GNU. For example, if you have shell scripts in OS X you want to port directly to iOS.

B) There are a few cases where the Darwin utilities are more suited to Apple OSes than GNU ones, plus cases where there exist no GNU ones exist.

To sum A+B, TL,DR, whatever: It's not philosophical reasons. The argument that Saurik makes about <i>anyone</i> is tinted (and tainted) by his point of view, which he generalizes in this case as an absolute truth. Likewise about grep/find being barely above unusable. Seriously? I use them all the time. Once you adjust to the syntax, it actually makes sense. De gustibus non disputandum est (matter of personal taste, I guess).

And also:
C) A ton of the Cydia utilities have not been updated in SO long they simply don't work. One example which springs to mind is kextstat (32-bit, unsupported APIs).

Saurik is welcome in this forum. I tried reaching out to him over TWTR, that didn't work. Big fan of your work, man!

--End quote --

Maybe I should create my own package deployment mechanism and Cydia alternative one of these days :-)

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Tue Apr 05, 2016 8:37 pm
by saurik
Administrator wrote:A) "Decades old" vs. "Minutes old" is wrong. The compiled utilities are from Darwin, which has been around *and used by AAPL* for at least the past 14 years. So I don't get that argument. Besides, people coming from OS X want the same experience - and that's why it makes sense to port the OS X utilities, rather than use GNU. For example, if you have shell scripts in OS X you want to port directly to iOS.


The probability that you have a script which works using a BSD tool and not a GNU one is much lower than vice versa... even vanishingly low: people generally only bother to support BSD tools if they are going to drop all the way to the POSIX subset. However, there are tons of packages people want to be able to use and compile that are designed by developers who are doing most of their testing on a Linux distribution. The idea that someone has a script that requires a BSD variant of a utility seems like a niche problem that is so strange as to be artificial, but I have run into GNU dependencies almost constantly. The tools are simply better: they have much more functionality.

The reality is that most people who use OS X and not Linux tend to be so entry-level in their workflow that they probably barely understand how the tools work: there are only a handful of people like yourself who actually live and breathe OS X. We didn't even and still don't have those people in the jailbreak teams: most of them used Windows (with Cygwin) or Linux; the only person who comes to mind as an OS X native developer who worked on jailbreaks was wizdaz.

Administrator wrote:B) There are a few cases where the Darwin utilities are more suited to Apple OSes than GNU ones, plus cases where there exist no GNU ones exist.


In the cases where tools only exist for Darwin I generally ship a package containing just those tools extracted from the rest of the sources. If there is some tool you want, tell me! I seriously wasted a ton of time getting a lot of niche stuff no one even knows what it does compiling a long time ago from these Darwin-specific packages, and it all seems like a waste of time... no one builds scripts that rely on those commands as most people who bother to develop low-level stuff that supports OS X have a primary deployment target of a Linux server and are only supporting OS X as an "also works" so web developers can have a mobile testing platform.

Administrator wrote:Likewise about grep/find being barely above unusable. Seriously? I use them all the time. Once you adjust to the syntax, it actually makes sense. De gustibus non disputandum est (matter of personal taste, I guess).


The BSD version of find has such a minimal subset of functionality it is downright crippling, and the BSD version of grep is well known to be orders of magnitude slower than the GNU one: Apple finally switched only a few years ago as part of their entirely-philosophical (and if you question that...) process of purging GNU code from their operating system, and it caused rather massive uproar. If you seriously don't regularly run into "ugh, this is taking forever, wtf just happened... omg, this is BSD grep?!?" I am going to have to ask what your usage pattern is for the terminal :(.

Administrator wrote:And also:
C) A ton of the Cydia utilities have not been updated in SO long they simply don't work. One example which springs to mind is kextstat (32-bit, unsupported APIs).


I spent an immense amout of time and effort with both planetbeing and comex looking into kernel extensions and also got some feedback (under a weird form of camafluage that they eventually caught) to try to get kernel extensions working, and it turns out that to the extent to which we succeeded was entirely pointless as Apple removed the kernel extension linker from the kernel. There is thereby almost no reason to have kextstat: no one from the community has ever come to me with a need for kextstat given that kextload is impossible. I only still ship that package at all because it is was once shipped and in case someone is still playing with this stuff on iOS3.

FWIW, my standpoint continues to be the same: if someone comes to me saying they need some flag that is only featured in a newer version of a package, I prioritize it and release it pretty quickly (sometimes in minutes; though right now my turnaround is likely to be closer to two days for various reasons). While people sometimes complain about a utility being out of date, they never tell me why, and under cross examination it always turns into "I just hate that it has an old version number there". I dare you to use a version of Linux from 2008 and seriously sit there going "omg, cp is out of date and is missing this flag", but people do that every day when they use current versions of BSD utilities that are missing things GNU tools have had since as long as I have been using them :/.

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Tue Apr 05, 2016 8:49 pm
by morpheus
WOW! I am outright honored to have you here, man! Thank you for coming!

About the whole package issue - I'm not going to war over it; you are certainly entitled to decide what goes in and out. I still think it would be nice to have support for 64-bit binaries - which is what got me started with this in the first place. If you want to bundle them into some other repo, that would be appreciated - I would at least let people choose. If not, no worries - I guess people who want it get it off the binpack anyway. IMHO, I see lots of value in having iOS provide the same binaries as OS X (especially kextstat, even though loading is (almost) impossible (but unloading is trivial :-) ). Plus my own personal binaries (procexp, jtool) are super useful on the device itself, and could gain more exposure if in a trusted repo. Though on second thought I update so frequently it could be a pain.

So I guess stick with whatever binaries you see fit - I applaud and commend you for getting the jailbreak world to where it did thus far.

J

P.S - Incidentally, if you want to review and/or pre-read MOXiI 2nd Ed (have you read the 1st Ed, by chance?), I'd be honored!

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Sat Apr 23, 2016 2:41 pm
by minicoin
So, it's been a while, but I've finally figured out how to compile stuff on iOS now. So far I've got Git to compile (although it took a long time). Problem is, the Git build process ends up creating around 280 MB of binaries. Whoops!

So, when installing the ffi gem, Ruby calls gcc and compiles the ffi native extensions. Of course, it fails, because it can't find an SDK to use. Is there some way to override this? I tried CFLAGS='-isysroot /path/to/iPhoneOS.sdk' but it doesn't seem to work.

That brings me to another question: if GCC/Clang fails to find an SDK, where is it looking? Perhaps I can place an SDK in where it is looking and get the ffi gem to build properly...

Re: Request: Ruby and RubyGems in the iosbinpack

PostPosted: Sat Apr 23, 2016 5:16 pm
by Siguza
The clang help states that the default value for -isysroot is "/".
But unless you can and want to resize the root partition, putting the SDK there is probably not going to work.
I'd simply put a wrapper script at /usr/local/bin/clang, like:
Code: Select all
#!/bin/bash
/usr/bin/clang -isysroot /path/to/iPhoneOS.sdk "$@";