nokogiri 1.6.0 fails to load embedded version of libxml2 if absolute path changes #923

Merged
merged 8 commits into from Oct 22, 2013

Conversation

Projects
None yet
8 participants
@knu
Member

knu commented Aug 17, 2013

Our build system does a bundle install --path ./bundler on one machine; then tars up the result and sends it to the rest of production.

Unfortunately the tar-ball gets extracted into a different directory on the production servers from the temporary build server directory, which means that the absolute path hard-coded into nokogiri.so at compile time is wrong. This means that nokogiri picks up the system version of libxml2 and not the embedded version and you get a warning on start-up.

I think this is fixable on Linux by using Dylib.dlopen to open the libxml2.so file eagerly; not certain the correct way to fix on a Mac.

To replicate see the instructions at https://github.com/ConradIrwin/nokogiri-test.

@envygeeks

This comment has been minimized.

Show comment Hide comment
@envygeeks

envygeeks Jun 17, 2013

This might be related so I'm going to stick this here for now but if it's not then I'll move it to it's own ticket. We have a similar problem but in a way a bit opposite of his result. We package our production scripts and send them off and they too get untared into a different directory.

Instead of doing what @ConradIrwin states, for us, it claims that it was built against 2.8.0 of libxml2 and loaded 2.9.0 through dynamic linking, none of our dev or production servers contain libxml 2.8.0 and it was in-fact built against 2.9.0 but this was triggered by the paths changing and it being unpackaged into /srv instead of /home/user/development/user/project.

The message: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.9.0

This might be related so I'm going to stick this here for now but if it's not then I'll move it to it's own ticket. We have a similar problem but in a way a bit opposite of his result. We package our production scripts and send them off and they too get untared into a different directory.

Instead of doing what @ConradIrwin states, for us, it claims that it was built against 2.8.0 of libxml2 and loaded 2.9.0 through dynamic linking, none of our dev or production servers contain libxml 2.8.0 and it was in-fact built against 2.9.0 but this was triggered by the paths changing and it being unpackaged into /srv instead of /home/user/development/user/project.

The message: Nokogiri was built against LibXML version 2.8.0, but has dynamically loaded 2.9.0

@eolamey

This comment has been minimized.

Show comment Hide comment
@eolamey

eolamey Jun 22, 2013

This problem also makes it difficult to build packages for nokogiri, as I used to do here.

eolamey commented Jun 22, 2013

This problem also makes it difficult to build packages for nokogiri, as I used to do here.

@sage-andrew-taylor

This comment has been minimized.

Show comment Hide comment
@sage-andrew-taylor

sage-andrew-taylor Jul 28, 2013

I'm seeing this problem, and I agree it's an issue. Have we any expectation that this will be fixed ? I've just mailed the mailing list. I would expect that libxml2_path would refer to the relative ./vendor/bundle path at the time of execution not the ./vendor/bundle path at the time it was built.

https://gist.github.com/sage-andrew-taylor/cbdd3c6852e2490e5e00

Thanks

andrew

I'm seeing this problem, and I agree it's an issue. Have we any expectation that this will be fixed ? I've just mailed the mailing list. I would expect that libxml2_path would refer to the relative ./vendor/bundle path at the time of execution not the ./vendor/bundle path at the time it was built.

https://gist.github.com/sage-andrew-taylor/cbdd3c6852e2490e5e00

Thanks

andrew

@hone

This comment has been minimized.

Show comment Hide comment
@hone

hone Aug 2, 2013

We're running into this issue on Heroku as well. Our build environment is different than our runtime, which is spewing this error.

hone commented Aug 2, 2013

We're running into this issue on Heroku as well. Our build environment is different than our runtime, which is spewing this error.

@knu

This comment has been minimized.

Show comment Hide comment
@knu

knu Aug 3, 2013

Member

I guess we should link the bundled libraries statically. Since they are only used by nokogiri.so, there is no benefit we can get from dynamic linking. Static linking allows us to remove the stuff "ports" have installed after successfully building the extension as a bonus.

Member

knu commented Aug 3, 2013

I guess we should link the bundled libraries statically. Since they are only used by nokogiri.so, there is no benefit we can get from dynamic linking. Static linking allows us to remove the stuff "ports" have installed after successfully building the extension as a bonus.

@hone

This comment has been minimized.

Show comment Hide comment
@hone

hone Aug 3, 2013

+1 on static linking.

hone commented Aug 3, 2013

+1 on static linking.

@hone hone referenced this pull request in heroku/heroku-buildpack-ruby Aug 5, 2013

Merged

nokogiri should compile with system libs #124

@Peeja

This comment has been minimized.

Show comment Hide comment
@Peeja

Peeja Aug 7, 2013

Hello. This is a message for people following the URL in the message shown by the new version of the Heroku Ruby buildpack, as of heroku/heroku-buildpack-ruby#124.

Since that landed, I've been unable to deploy because my slug build times went over 15 minutes. Turns out this is because the new version of the buildpack clears the Bundler cache to get rid of any old builds of Nokogiri. If you have enough dependencies, that slows things down enough to time out a slug build.

Fortunately I've solved the problem. If you've run into this problem then your cache has already been cleared, so the buildpack no longer needs to clear it for you. I adjusted the buildpack on a branch to skip clearing the cache. First, point to the tweaked buildpack:

$ heroku config:set [-a app-name] BUILDPACK_URL=https://github.com/nerdfighteria/heroku-buildpack-ruby.git#nokogiri-busted-cache-fix

Then push to deploy as normal. It's possible you'll need to try to deploy more than once: each time you'll get through re-caching more gems. (That would mean you have a whole lot of dependencies, though.)

Once you've deployed, you can switch back to the main-line buildpack. In the future, it will see that you've built with a newer version of the buildpack and that you therefore don't need your cache cleared.

$ heroku config:unset [-a app-name] BUILDPACK_URL

Hope that's helpful to someone!

Peeja commented Aug 7, 2013

Hello. This is a message for people following the URL in the message shown by the new version of the Heroku Ruby buildpack, as of heroku/heroku-buildpack-ruby#124.

Since that landed, I've been unable to deploy because my slug build times went over 15 minutes. Turns out this is because the new version of the buildpack clears the Bundler cache to get rid of any old builds of Nokogiri. If you have enough dependencies, that slows things down enough to time out a slug build.

Fortunately I've solved the problem. If you've run into this problem then your cache has already been cleared, so the buildpack no longer needs to clear it for you. I adjusted the buildpack on a branch to skip clearing the cache. First, point to the tweaked buildpack:

$ heroku config:set [-a app-name] BUILDPACK_URL=https://github.com/nerdfighteria/heroku-buildpack-ruby.git#nokogiri-busted-cache-fix

Then push to deploy as normal. It's possible you'll need to try to deploy more than once: each time you'll get through re-caching more gems. (That would mean you have a whole lot of dependencies, though.)

Once you've deployed, you can switch back to the main-line buildpack. In the future, it will see that you've built with a newer version of the buildpack and that you therefore don't need your cache cleared.

$ heroku config:unset [-a app-name] BUILDPACK_URL

Hope that's helpful to someone!

@ghost ghost assigned knu Aug 8, 2013

@knu

This comment has been minimized.

Show comment Hide comment
@knu

knu Aug 8, 2013

Member

I'm currently working on static linking.

Member

knu commented Aug 8, 2013

I'm currently working on static linking.

@knu

This comment has been minimized.

Show comment Hide comment
@knu

knu Aug 8, 2013

Member

I've just pushed my commits to the static_clean branch which makes nokogiri statically link the packaged libraries by default.

Would you guys give it a try? Run rake install_gem and see what ldd "$(gem which nokogiri/nokogiri.so)" gives.

@flavorjones Could you review my changes? The branch also includes a patch that cleans files generated by ports that are unnecessary to run nokogiri, which will hopefully eliminate recent complaints on how nokogiri installation is bloated.

Member

knu commented Aug 8, 2013

I've just pushed my commits to the static_clean branch which makes nokogiri statically link the packaged libraries by default.

Would you guys give it a try? Run rake install_gem and see what ldd "$(gem which nokogiri/nokogiri.so)" gives.

@flavorjones Could you review my changes? The branch also includes a patch that cleans files generated by ports that are unnecessary to run nokogiri, which will hopefully eliminate recent complaints on how nokogiri installation is bloated.

knu added some commits Aug 8, 2013

Do not search system directories so eagerly, but let user specify opt…
…ions.

Now that we use packaged libraries by default, Nokogiri should build
for most usrs without bothering system libraries.

We have the options --with-{xml2,xslt,exslt}-{dir,include,lib}=dir
supported and also consult pkg-config(1) for libxml2, libxslt and
libexslt.  What else should you want?
Link packaged libraries statically by default.
A new option --disable-static allows user to link packaged libraries
dynaminally.

Fix priority problems with include directories and library directories
by manipulating $CPPFLAGS, $LIBPATH and $libs correctly.
@knu

This comment has been minimized.

Show comment Hide comment
@knu

knu Aug 21, 2013

Member

@flavorjones What do you think about the changes?

Member

knu commented Aug 21, 2013

@flavorjones What do you think about the changes?

@hone

This comment has been minimized.

Show comment Hide comment
@hone

hone Sep 20, 2013

@flavorjones bump from gogaruco :)

hone commented Sep 20, 2013

@flavorjones bump from gogaruco :)

@larskanis

This comment has been minimized.

Show comment Hide comment
@larskanis

larskanis Oct 13, 2013

Member

Why remove the tmp directory only, when it's inside another tmp directory? While gem install the build takes place within ext/nokogiri, so this deletion step is not executed, then. On the other hand, while rake compile the whole clean step is skipped.

If I comment this condition out, the deletion works as expected - while gem install but not within the development work tree. Tested with static linking on Ubuntu 13.10 with rvm and ruby 2.0.0-p247 and 1.9.3-p448.

Why remove the tmp directory only, when it's inside another tmp directory? While gem install the build takes place within ext/nokogiri, so this deletion step is not executed, then. On the other hand, while rake compile the whole clean step is skipped.

If I comment this condition out, the deletion works as expected - while gem install but not within the development work tree. Tested with static linking on Ubuntu 13.10 with rvm and ruby 2.0.0-p247 and 1.9.3-p448.

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 14, 2013

Member

The comment below should explain it all. Note that this --clean part is executed right before install.

Member

knu replied Oct 14, 2013

The comment below should explain it all. Note that this --clean part is executed right before install.

This comment has been minimized.

Show comment Hide comment
@larskanis

larskanis Oct 14, 2013

Member

Yes the --clean part is executed after the extension build but before the install. So root + 'tmp' can not be removed, but pwd + 'tmp' can be removed, regardless whether static linked or not. Line 22 prohibits deletion of pwd + 'tmp' directory for gem install, there most of the amount of data resides. So the comment above is more a bug report than a question.

Member

larskanis replied Oct 14, 2013

Yes the --clean part is executed after the extension build but before the install. So root + 'tmp' can not be removed, but pwd + 'tmp' can be removed, regardless whether static linked or not. Line 22 prohibits deletion of pwd + 'tmp' directory for gem install, there most of the amount of data resides. So the comment above is more a bug report than a question.

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 14, 2013

Member

That is because files under "tmp" is not garbage for developers. It's essential for debugging. They also help fix-and-rebuild iteration in that they save building time.

Member

knu replied Oct 14, 2013

That is because files under "tmp" is not garbage for developers. It's essential for debugging. They also help fix-and-rebuild iteration in that they save building time.

This comment has been minimized.

Show comment Hide comment
@larskanis

larskanis Oct 14, 2013

Member

That's true for tmp within the development work tree. But ext/nokogiri/tmp within the gem installation tree can be and should be deleted after gem install. But it is not. That's what we are talking about regarding the installation size, don't we?

Member

larskanis replied Oct 14, 2013

That's true for tmp within the development work tree. But ext/nokogiri/tmp within the gem installation tree can be and should be deleted after gem install. But it is not. That's what we are talking about regarding the installation size, don't we?

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 14, 2013

Member

Gem install is not designed to remove anything after installation in the first place, and there is no reason nokogiri alone should do that.
Our source files and object files are useful when investigating a bug, because most bugs are on our side, not in the upstream.

Member

knu replied Oct 14, 2013

Gem install is not designed to remove anything after installation in the first place, and there is no reason nokogiri alone should do that.
Our source files and object files are useful when investigating a bug, because most bugs are on our side, not in the upstream.

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 14, 2013

Member

Please ignore the last part, I intended to include all the source files used for build.

Member

knu replied Oct 14, 2013

Please ignore the last part, I intended to include all the source files used for build.

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 14, 2013

Member

Maybe there can be an option to remove them, if needs be.

Member

knu replied Oct 14, 2013

Maybe there can be an option to remove them, if needs be.

This comment has been minimized.

Show comment Hide comment
@larskanis

larskanis Oct 14, 2013

Member

True, I follow you in these respects. It's only that the issue of the two people in #952 and #977 is not properly addressed, because the build directory of the upstream libraries (ext/nokogiri/tmp) is not deleted.

To be honest, it's not that I'm really interested in this point, but I did the requested testing of this branch, to bring it in a clearer state, with the wish to merge issue #976 someday.

Member

larskanis replied Oct 14, 2013

True, I follow you in these respects. It's only that the issue of the two people in #952 and #977 is not properly addressed, because the build directory of the upstream libraries (ext/nokogiri/tmp) is not deleted.

To be honest, it's not that I'm really interested in this point, but I did the requested testing of this branch, to bring it in a clearer state, with the wish to merge issue #976 someday.

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 22, 2013

Member

On second thought, I decided to just remove the build directory unless --disable-clean is given.
Thanks for your feedback.

Member

knu replied Oct 22, 2013

On second thought, I decided to just remove the build directory unless --disable-clean is given.
Thanks for your feedback.

@larskanis

This comment has been minimized.

Show comment Hide comment
@larskanis

larskanis Oct 13, 2013

Member

@knu: I did some testing of your static_clean branch on Ubuntu-13.10. After rake gem I used something like env MAKE="make -j2 V=1" gem inst -l pkg/nokogiri-1.6.0.gem --verbose -- --disable-clean to install the gem. Beside the issue above, everything worked.

When installed with --disable-static I get the following shared object:

$ ldd `gem which nokogiri/nokogiri.so `
        linux-vdso.so.1 =>  (0x00007fffb53fe000)
        libruby.so.2.0 => /home/lars/.rvm/rubies/ruby-2.0.0-p247/lib/libruby.so.2.0 (0x00007f4d12ff0000)
        libexslt.so.0 => /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxslt/1.1.28/lib/libexslt.so.0 (0x00007f4d12ddb000)
        libxslt.so.1 => /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxslt/1.1.28/lib/libxslt.so.1 (0x00007f4d12b9c000)
        libxml2.so.2 => /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxml2/2.8.0/lib/libxml2.so.2 (0x00007f4d1283d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d1243c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4d1221f000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4d12017000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d11e12000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4d11bd9000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4d118d5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4d1369e000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4d116bb000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f4d11499000)

When installed with default params it results in the following shared object:

$ ldd `gem which nokogiri/nokogiri.so `
        linux-vdso.so.1 =>  (0x00007fff62389000)
        libruby.so.1.9 => /home/lars/.rvm/rubies/ruby-1.9.3-p448/lib/libruby.so.1.9 (0x00007f36128aa000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f361256c000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3612353000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3612136000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3611f2d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3611b66000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3611962000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f3611728000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f361313e000)

I wonder about the missing reference to liblzma although configure.log of libxml2 has

Checking lzma
checking lzma.h usability... yes
checking lzma.h presence... yes
checking for lzma.h... yes
checking for lzma_code in -llzma... yes

Both variants are usable to run ruby -Ilib:test test/test_reader.rb successfully.

Beside that I'm not sure if extconf.rb lines 244-258 are really necessary, but I didn't do any tests to that. Line 272 is probably not very portable across compilers other than gcc.

By all means the clean step is a clever mechanism.

Member

larskanis commented Oct 13, 2013

@knu: I did some testing of your static_clean branch on Ubuntu-13.10. After rake gem I used something like env MAKE="make -j2 V=1" gem inst -l pkg/nokogiri-1.6.0.gem --verbose -- --disable-clean to install the gem. Beside the issue above, everything worked.

When installed with --disable-static I get the following shared object:

$ ldd `gem which nokogiri/nokogiri.so `
        linux-vdso.so.1 =>  (0x00007fffb53fe000)
        libruby.so.2.0 => /home/lars/.rvm/rubies/ruby-2.0.0-p247/lib/libruby.so.2.0 (0x00007f4d12ff0000)
        libexslt.so.0 => /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxslt/1.1.28/lib/libexslt.so.0 (0x00007f4d12ddb000)
        libxslt.so.1 => /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxslt/1.1.28/lib/libxslt.so.1 (0x00007f4d12b9c000)
        libxml2.so.2 => /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxml2/2.8.0/lib/libxml2.so.2 (0x00007f4d1283d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d1243c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4d1221f000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4d12017000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d11e12000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4d11bd9000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4d118d5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4d1369e000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4d116bb000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f4d11499000)

When installed with default params it results in the following shared object:

$ ldd `gem which nokogiri/nokogiri.so `
        linux-vdso.so.1 =>  (0x00007fff62389000)
        libruby.so.1.9 => /home/lars/.rvm/rubies/ruby-1.9.3-p448/lib/libruby.so.1.9 (0x00007f36128aa000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f361256c000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3612353000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3612136000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3611f2d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3611b66000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3611962000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f3611728000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f361313e000)

I wonder about the missing reference to liblzma although configure.log of libxml2 has

Checking lzma
checking lzma.h usability... yes
checking lzma.h presence... yes
checking for lzma.h... yes
checking for lzma_code in -llzma... yes

Both variants are usable to run ruby -Ilib:test test/test_reader.rb successfully.

Beside that I'm not sure if extconf.rb lines 244-258 are really necessary, but I didn't do any tests to that. Line 272 is probably not very portable across compilers other than gcc.

By all means the clean step is a clever mechanism.

@knu

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 14, 2013

Member

@larskanis Thanks for testing. Here's a couple of comments as a reponse.

  • As for portability, some kind of guard should indeed be added that checks if the compiler/linker flags are supported.
  • LZMA support is not used by Nokogiri, so it shouldn't be a problem as long as it builds and loads fine.
Member

knu commented Oct 14, 2013

@larskanis Thanks for testing. Here's a couple of comments as a reponse.

  • As for portability, some kind of guard should indeed be added that checks if the compiler/linker flags are supported.
  • LZMA support is not used by Nokogiri, so it shouldn't be a problem as long as it builds and loads fine.
@knu

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 22, 2013

Member

I'll merge this after making it an option to entirely remove the tmp directory, unless any objection is raised.

Member

knu commented Oct 22, 2013

I'll merge this after making it an option to entirely remove the tmp directory, unless any objection is raised.

@knu knu merged commit f5ef8f8 into master Oct 22, 2013

@knu

This comment has been minimized.

Show comment Hide comment
@knu

knu Oct 22, 2013

Member

I made it just remove the ports build directory by default.

Member

knu commented Oct 22, 2013

I made it just remove the ports build directory by default.

@byrnejb

This comment has been minimized.

Show comment Hide comment
@byrnejb

byrnejb Nov 20, 2013

Where is this at? When will nokogiri go back to building with system libs?

byrnejb commented Nov 20, 2013

Where is this at? When will nokogiri go back to building with system libs?

gbenedict added a commit to RedFunnel/heroku-buildpack-ruby that referenced this pull request Jan 9, 2014

nokogiri should compile with system libs
As of nokogiri 1.6.0, they default to using the vendored libxml2 libs.
This is problematic for two reasons. First, with the way the heroku
build environment works,
sparklemotion/nokogiri#923. This means it
won't link nokogiri.so properly since it's dependent on hardcoded paths
that don't exist during runtime. Second, compiling libxml2 and friends
is unnecessary since we have them already setup. We should skip this to
speed up deploys.

squeedee added a commit to cloudfoundry/ruby-buildpack that referenced this pull request Apr 10, 2014

nokogiri should compile with system libs
As of nokogiri 1.6.0, they default to using the vendored libxml2 libs.
This is problematic for two reasons. First, with the way the heroku
build environment works,
sparklemotion/nokogiri#923. This means it
won't link nokogiri.so properly since it's dependent on hardcoded paths
that don't exist during runtime. Second, compiling libxml2 and friends
is unnecessary since we have them already setup. We should skip this to
speed up deploys.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment