Heroku environment

[MikaelMollberg]

Hi, I tried installing rice on heroku but received this error.

remote: extconf.rb:23:in

': Unfortunately Rice does not work against a Ruby without any shared libraries. (RuntimeError) remote: You'll need to rebuild Ruby with --enable-shared to use this library.

I contacted their support and they said that ruby is built with --enable-shared and told me to contact the maintainer. Any idea what could be wrong?

According to them Ruby is compiled with the following flags.

'--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib/ruby1.9.1' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-pthread' '--enable-shared' '--disable-rpath' '--disable-install-doc' '--with-vendordir=/usr/lib/ruby/vendor_ruby' '--with-sitedir=/usr/local/lib/site_ruby' '--program-suffix=1.9.1' '--with-soname=ruby-1.9.1' '--enable-ipv6' '--with-dbm-type=gdbm_compat' '--with-tklib=tk8.5' '--with-tcllib=tcl8.5' '--with-tcl-include=/usr/include/tcl8.5' '--with-tk-include=/usr/include/tcl8.5' '--with-tcl-lib=/usr/lib/x86_64-linux-gnu' '--with-tk-lib=/usr/lib/x86_64-linux-gnu' '--with-bundled-sha1' '--with-bundled-md5' '--with-bundled-rmd160' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -fno-strict-aliasing' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -L/build/buildd/ruby1.9.1-1.9.3.484/debian/lib' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -fno-strict-aliasing'

[Kagetsuki]

@jasonroelofs Sorry for filling this thread with crap, but I'll give you a status update: I got some info that automake generates static libs in a very specific way and this is likely the issue. Apparently most people who generate libs with automake will use libtool (which has a full set of bindings and helper methods available in vanilla automake) to generate .la pseudo libraries which are converted into whatever type of library is needed at compile/link time. I'm attempting to convert the build chain to generate and build with these .la libraries from the current static build.

Clarification: If what I'm being told is in fact correct, automake/libtool will actively disable PIC for static compilation. In this case we're being told to add -fPIC likely because some automake magic is disabling it at some key point in the build chain. Furthermore, when using libtool, you really need to tell it to disable static building completely to get it to really build portable PIC code as libtool will default to try and optimize to the architecture/configuration it's being run on.

Update: I have the .la building but past that I can't seem to coax it into actually building an .so to link against or to get the .la linked or whatever libtool is supposed to do. I'm reminded of why I started using CMake instead of automake.

[jasonroelofs]

Yeah I wouldn't be opposed to moving to CMake, but the big problem there is that it then requires people to have CMake installed to be able to build Rice and build gems that are using Rice. We use autotools as we can make a decent assumption that a system with a C++ compiler will also have the autotools installed.

[schneems]

The problems you ran into using our docker image may have been to using the default installed Ruby version. When you deploy with the buildpack we download and unpack a new version for example 2.2.3 https://heroku-buildpack-ruby.s3.amazonaws.com/cedar-14/ruby-2.2.3.tgz.

[Kagetsuki]

@jasonroelofs Aah I didn't mean to imply we should move to CMake, just that I'm used to CMake because I made the decision to use it a long time ago after comparing generative make systems and found CMake to be the one I liked the most. Moving to CMake now would be a massive undertaking which I would only recommend if for some reason automake just won't work.

Status update: I successfully retooled for libtools and have it generating a librice.so which links just as well as the non-libtools librice.a build; which is to say it didn't actually fix the problem at all.

We do have librice generating on static environments. Instead of continuing to prod at the build chain I'm going to try and manually write a build line to see if I can get anything to work.

[Kagetsuki]

@schneems Any idea where I can find the build flags that are used to generate that ruby? And I hate to ask again, but any chance we can get some idea as to why we can't have a dynamic ruby on heroku?

[schneems]

I don't think dynamic built rubies is a possibility. Using static built libs solves a host of otherwise hard to debug and solve problems. Here's flags https://github.com/hone/docker-heroku-ruby-builder/blob/48d17c8a02e0b779dec19947015a8b83bdad508c/build.rb#L140-L142

[Kagetsuki]

@schneems I really need some clarification on why and I need it now. I have an app on heroku that I currently can't update because of this and I NEED to update it. This is years of work and the future of my business coming to a halt because of one "small" issue. On top of that, as I mentioned above, I HAVE successfully build dynamic ruby on a dyno; so I at least know it can be built and run in a tethered shell - so I'm not buying "it can't be done because of reasons".

[schneems]

Regardless of what you will and won't "buy" we won't be changing the way future rubies are compiled or recompiling any. I recommend you either fork the buildpack and compile your own ruby, or deploy somewhere that does not provide pre-compiled executables. For some perspective rubygems.org has 109,873 gems with over 6,511,481,79 downloads. Of all of those gems, this is the only one that i've seen in memory that hasn't been able to install on Heroku due to how we build Ruby.

I understand you're frustrated and you're on a deadline. I'm interested in providing what help I can. Recompiling all the rubies on the platform are not on that list.

[Kagetsuki]

@schneems

I recommend you either fork the buildpack and compile your own ruby

I'm already doing this but I NEED to know if you already know of some issue with dynamic rubies. I've asked you this question over and over: what problems are you aware of with dynamic ruby on heroku?

I'm not attacking you; I just need this information and I've asked over and over and never gotten a straight answer. Please, would you please just tell me what the issues are with dynamic rubies on heroku. You're the keymaster here, you're the man who knows how things work - we don't. Without your help and guidance we're flying blind. Is my attempt to modify a buildpack to create a dynamic ruby a fools errand?

~~Notes/update: Props on the whole buildpack framework - my head is spinning trying to figure it all out. I keep getting stuck on different points and it's taking me forever because I've never really used docker and I don't have a complete image of how a buildpack is even handled by heroku.~~ ^update: I've given up on this. @schneems is correct in that messily forcing a dynamic ruby on heroku isn't the correct / sustainable solution. Much respect @schneems and thank you for your time.

this is the only one that i've seen in memory that hasn't been able to install on Heroku

We're talking about building, not installing - and that gave me an idea for a kludge that looks like it will let me deploy and update but it will be absolutely specific to heroku - so not a final solution. I'll report if it worked; but from what I'm seeing passenger actually did a similar hack a little while ago to overcome some temporary build issues almost a year ago.

[Kagetsuki]

@jasonroelofs I'm putting @lev-k on this from monday morning. He's a savant.

This particular issue has gotten pretty junked up (mostly due to me freaking out). We've also determined this issue is not Heroku specific but rather an issue with libruby-static.a specifically. What do you say to maybe closing this and starting up a separate issue like "Static build".

Also, there are a few changes I'd like to propose:

1. There's no reason to actually package tests inside the gem. I suggest removing tests and samples from the gemspec and putting in a conditional to see if they are included in the build chain and skipping them if they are not. This will cut down on deployment time and size as currently tests are being built each time the rice gem is used.
2. Same as 1 but with docs - if they're all being built inside the gem and not exposed then bundling them just adds build time and load size.
3. I already did this in my fork but rice.gemspec isn't being bundled in the actual gem which causes issues if you deploy a pre-compiled gem or if you want to bundle a vendorized gem. Do you have any issues with bundling the gemspec?
4. I'm wondering if there's specific issues with windows builds you're aware of? If so maybe @lev-k can kill two birds with one stone this week.

[jasonroelofs]

This ticket has definitely gone in a direction I'm not particularly happy about. Lets start a new discussion for sure, but to answer your points here:

1) Having tests in the gem are the proof that the rice gem is actually usable on the current computer. It proves that not only is librice built right but that you're able to link with Ruby as well so you can be sure that if gem install rice succeeded, you can be sure Rice isn't the source of any further compilation problems. 2) Keeping generated docs out of the gem makes sense. They are rdoc and not something people would be able to use. 3) I'm not sure if that's expected or an oversight, will take a look. 4) I haven't touched building on Windows for a long time, as I don't do any dev on that environment.

[Kagetsuki]

1. Got it. Makes sense.
2. OK.
3. It's not absolutely necessary but all it is is adding "rice.gemspec" to the files list and it makes the gem usable as-is in the situations I listed above.
4. OK, after/if we get static fixed we'll give it a dry run and see what the status is.

[Kagetsuki]

@jasonroelofs I'm afraid this may be a final status update from me.

• Absolutely no success with static linking in rice. We can statically link a raw C++ demo but for some reason anything to do with rice just won't go. I have a suspicion it has to do with some mixing of static and dynamic libraries but we couldn't find a combination of args to ld that would work (and trust me, we tried a lot of different combinations).
• Rice is NOT the only component encountering static/dynamic issues. There's a variety of issues that look loosely related on github and the ruby issue tracker all with a common theme: they started occurring at Ruby 2.2.2. That lines up with the point that I couldn't use my precompiled hack of vendorizing libruby.so. Perhaps I would have success with some of the things we tried in the last few days if we tried them on 2.2.0 but at this point we just don't have the time or energy; nor would it do anything other than to prove something changed without actually fixing anything for 2.2.2+.
• Windows build would require a big refactor. It's basically way more work than we're willing to put in.

If anyone has any ideas it would be nice to hear them. Otherwise @jasonroelofs I think this issue is spent and should be closed.

@schneems if you're going to be at Ruby Kaigi give me a heads up - I owe you a good meal or a few drinks over this one.

[Kagetsuki]

In the end were were forced to migrate to a different method without rice and doing so required I actually do make a buildpack and learn how buildpacks work; which was actually easier than I thought. Basically you can make a dynamic ruby buildpack, it will run, and rice will build on it. According to @schneems this should not be done so I'm basically going to stop there.

Essentially, as it stands now, your options are:

• Write your own wrapper using a raw bindings / rake-compiler / etc. For a C++ project this is a big hit in terms of time/effort as in any moderately sized project doing all the mappings will require a lot of handling code.
• Use a different wrapper generator framework like SWIG. There are two major demerits here:
  1. Every wrapper generator we saw had some sort of deficiency which Rice had overcome. EG: SWIG has strange issues with nested modules and a few quirky points (the Ruby wrapping system needs some attention). Other C++ to Ruby wrapper systems are extremely niche and none were mature or full enough to really consider.
  2. Building requires you provide the generators and their dependencies in a buildpack.
• Roll a dynamic Ruby buildpack and hope the dynos don't blow up?

I'm still hoping someone fixes Rice for static rubies (and maybe for Windows too at some point?) so we can use it again in the future. It is hands down the most flexible wrapper/interface framework for C++ to Ruby.

With that said I'm officially dropping out of this discussion. Best of luck and thanks to everyone for their time and effort.

[jasonroelofs]

@Kagetsuki Understood, sorry we couldn't figure out a good solution for you, and thanks for the info and work you put into this. I'll put what you've figured out into documentation so we a good starting point if someone else wants to pick this up and try to continue on.

[Kagetsuki]

@jasonroelofs I'm sorry I couldn't get it to work. I was certain I could for a while there but that relocation issue is just an impassible roadblock. I honestly think it has something to do with Ruby core but for the life of me I can't figure out what it is, where it originates from, or when the patch was applied that lead to the issue.

As for my findings I'm not sure how public they should be made. I don't want to discourage anyone away from Rice and I'm worried that my comment may do so - but at the same time I don't want anyone to go through the month and a half of trying out countless different semi-solutions only to come to the conclusion that I did :disappointed: