Build against older glibc (please)

[mojodna]

trafficstars

We're using node-mapnik on Ubuntu 10.04 (and can't upgrade, since it's Heroku) as well as some RHEL 5.10 instances, so the pre-built binaries don't work. I'd love to use them though (esp. since compilation happens during deployment and slug size matters on Heroku). How difficult would it be to build on, say, 10.04 instead?

FWIW, here are the steps I followed to build a statically linked binary on Centos 5.10 (I think jpeg failed to link, but everything else was cool--theres a Dockerfile that walks through the steps):

https://github.com/mojodna/mapnik-packaging/tree/linux-static/linux-static

[springmeyer]

As a maintainer of not just node-mapnik but many other apps I have or plan to package with node-pre-gyp I need a way to automate binaries otherwise the overhead of releasing new versions is too great. Because the best solution for automation I've found so far is travis.ci I'm not inclined to support older distros than precise.

So, for this to be viable I either need an easy way to automate builds for linux using a distro older than precise, or I need to use something like listaller to build on travis/precise. My constraints:

• I'm hesitant to use listaller without a lot of testing
• Because travis/precise works well for my immediate needs its hard to justify spending time trying a different automation approach.

[mojodna]

I totally agree on the automation angle. I was hoping there was a way to easily target older distros using travis, either by using a different build image or with a well-established debootstrap / rinse procedure.

Ah, well. I'll keep an eye out to see if a straightforward solution presents itself at some point.

[springmeyer]

I'm not familiar with debootstrap (or really debian specific build tricks in general) but open to ideas. Regarding travis, yeah I've not seen any indication they'll allow control over the ubuntu version used, rather they just plan to promptly upgrade to the new LTS: https://github.com/travis-ci/travis-ci/issues/2046. So, this problem is about to get more severe if I stay with travis and don't have a method for targeting older versions. I think listaller is the next thing I'll test when I find time.

[mojodna]

Yeah, upgrading (relatively) immediately seems problematic for projects with binary artifacts.

A cursory Googling led to a couple of examples where people are using debootstrap to create chroots with different OSes, so that looks promising at some point:

• Running Travis CI tests on ARM architecture (using debootstrap and qemu--definitely a more complex setup)
• https://bitbucket.org/pypy/numpy/src/master/tools/travis-test.sh -- seems relatively straightforward

[springmeyer]

related, once mapnik 3.x is used we'll start needing c++11 symbols and I'll need to have a solution in mind for this. Currently tracking investigations at https://github.com/osmcode/node-osmium/issues/14

[springmeyer]

@mojodna so, to recap based on https://github.com/osmcode/node-osmium/issues/14#issuecomment-41743996:

• node-osmium requires c++11 support which means at a minimum GLIBC_2.17 and GLIBCXX_3.4.17 are required (at least when built with gcc 4.7 from ppa:ubuntu-toolchain-r/test on precise and I presume universally).
• because I plan to move node-mapnik to using Mapnik 3.x built with c++11 very soon, node-mapnik binaries will also have the same minimum libc and libstdc++ requirements.
• So that makes trying to target ubuntu precise libc/libstdc++ only possible by upgrading the compiler toolchain with ppa:ubuntu-toolchain-r/test and makes supporting even older libc/libstdc++ on lucid/heroku even more out of reach.

So, this ticket becomes un-actionable and I think we should close.

I'll be honest that my main goal in providing node-mapnik binaries is to make it easier to ship the exact code I want to users running the latest linux and osx systems. I'm seeing that trying to support older systems is incompatible with my objectives. So your idea of being able to override the host to point to an alternative set of binaries seems like the best approach going forward.

[springmeyer]

closing, tracking workaround at https://github.com/mapbox/node-pre-gyp/issues/74

[mojodna]

You probably tried it, but I figured I'd ask: did you try staticly linking libstdc++ and leaving libc dynamic (assuming that ppa:ubuntu-toolchain-r/test doesn't also upgrade libc)?

I'll be honest that my main goal in providing node-mapnik binaries is to make it easier to ship the exact code I want to users running the latest linux and osx systems. I'm seeing that trying to support older systems is incompatible with my objectives.

That's fair. Latest Linux would be Ubuntu 14.04+, then? The PPA requirement sucks if it's required for 12.04 runtimes.

I'm still gradually chipping away at the chroot approach (it would still help node-sqlite, etc.), though the libstdc++ requirement may be a non-starter after mapnik-3.x.

[springmeyer]

You probably tried it, but I figured I'd ask: did you try statically linking libstdc++ and leaving libc dynamic (assuming that ppa:ubuntu-toolchain-r/test doesn't also upgrade libc)?

I did not actually try this because it appears that libc was upgraded. I would love to be wrong on this, but it looks like the upgraded libstdc++ depended on upgraded libc symbols. I guess if you were to build your own libstdc++ against older libc..... >>>> rabbit hole.

That's fair. Latest Linux would be Ubuntu 14.04+, then?

Yes.

The PPA requirement sucks if it's required for 12.04 runtimes.

Yes, ppa:ubuntu-toolchain-r/test would be/will soon be) needed to run the binaries on 12.04.

I'm still gradually chipping away at the chroot approach (it would still help node-sqlite, etc.), though the libstdc++ requirement may be a non-starter after mapnik-3.x.

My thinking is the same: getting node-sqlite3 going on ancient libc is still a very worthy goal, but for C++ like Mapnik 3.x needing c++11, yep non-starter sadly I think.

[springmeyer]

re-opening. I don't have time to experiment more with this, but I also don't feel comfortable giving up until I've actually tried a few more things:

• statically link libstdc++, dynamically link glibc and try to do this against latest libstdc++ but older glibc. Challege is that libstdc++ will need to be custom built
• try using libc++/clang++ since that will likely be a more strait forward route if statically linking libc++.

[mojodna]

CircleCI will soon allow tests to run within specific Docker containers, so we could make one with sufficiently old versions of the core dependencies to produce artifacts from (ignoring the libstdc++ complexity):

https://circleci.com/integrations/docker

[springmeyer]

Very cool. Ignoring libstdc++/c++11 support, beyond that I think its only the libc version that matters.