invalid variable name: `CFLAGS\'

[Jeremy Rand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

I'm having trouble installing nokogiri on Debian Jessie.
(Specifically, on a Qubes 3 Whonix 11 template, but I doubt that
there's anything particularly unique about that setup.) Here's a
paste of what gets displayed in the terminal:



user@host:~$ sudo gem install nokogiri
Building native extensions. This could take a while...
ERROR: Error installing nokogiri:
ERROR: Failed to build gem native extension.

/usr/bin/ruby2.1 extconf.rb
checking if the C compiler accepts ... yes
Building nokogiri using packaged libraries.
checking for gzdopen() in -lz... yes
checking for iconv... yes
************************************************************************
IMPORTANT NOTICE:

Building Nokogiri with a packaged version of libxml2-2.9.2
with the following patches applied:
- 0001-Revert-Missing-initialization-for-the-catalog-module.patch
- 0002-Fix-missing-entities-after-CVE-2014-3660-fix.patch

Team Nokogiri will keep on doing their best to provide security
updates in a timely manner, but if this is a concern for you and want
to use the system library instead; abort this installation process and
reinstall nokogiri as follows:

gem install nokogiri -- --use-system-libraries
[--with-xml2-config=/path/to/xml2-config]
[--with-xslt-config=/path/to/xslt-config]

If you are using Bundler, tell it to use the option:

bundle config build.nokogiri --use-system-libraries
bundle install

Note, however, that nokogiri is not fully compatible with arbitrary
versions of libxml2 provided by OS/package vendors.
************************************************************************
Extracting libxml2-2.9.2.tar.gz into
tmp/x86_64-pc-linux-gnu/ports/libxml2/2.9.2... OK
Running patch with
/var/lib/gems/2.1.0/gems/nokogiri-1.6.6.2/ports/patches/libxml2/0001-Rev
ert-Missing-initialization-for-the-catalog-module.patch...
Running 'patch' for libxml2 2.9.2... OK
Running patch with
/var/lib/gems/2.1.0/gems/nokogiri-1.6.6.2/ports/patches/libxml2/0002-Fix
- -missing-entities-after-CVE-2014-3660-fix.patch...
Running 'patch' for libxml2 2.9.2... OK
Running 'configure' for libxml2 2.9.2... ERROR, review
'/var/lib/gems/2.1.0/gems/nokogiri-1.6.6.2/ext/nokogiri/tmp/x86_64-pc-li
nux-gnu/ports/libxml2/2.9.2/configure.log'
to see what happened. Last lines are:
========================================================================
configure: error: invalid variable name: `CFLAGS\'
========================================================================
*** 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/bin/ruby2.1
--help
--clean
--use-system-libraries
--enable-static
--disable-static
--with-zlib-dir
--without-zlib-dir
--with-zlib-include
--without-zlib-include=${zlib-dir}/include
--with-zlib-lib
--without-zlib-lib=${zlib-dir}/lib
--enable-cross-build
--disable-cross-build
/var/lib/gems/2.1.0/gems/mini_portile-0.7.0.rc2/lib/mini_portile/mini_po
rtile.rb:360:in
`block in execute': Failed to complete configure task (RuntimeError)
from
/var/lib/gems/2.1.0/gems/mini_portile-0.7.0.rc2/lib/mini_portile/mini_po
rtile.rb:331:in
`chdir'
from
/var/lib/gems/2.1.0/gems/mini_portile-0.7.0.rc2/lib/mini_portile/mini_po
rtile.rb:331:in
`execute'
from
/var/lib/gems/2.1.0/gems/mini_portile-0.7.0.rc2/lib/mini_portile/mini_po
rtile.rb:101:in
`configure'
from
/var/lib/gems/2.1.0/gems/mini_portile-0.7.0.rc2/lib/mini_portile/mini_po
rtile.rb:143:in
`cook'
from extconf.rb:278:in `block in process_recipe'
from extconf.rb:177:in `tap'
from extconf.rb:177:in `process_recipe'
from extconf.rb:475:in `<main>'

extconf failed, exit code 1

Gem files will remain installed in
/var/lib/gems/2.1.0/gems/nokogiri-1.6.6.2 for inspection.
Results logged to
/var/lib/gems/2.1.0/extensions/x86_64-linux/2.1.0/nokogiri-1.6.6.2/gem_m
ake.out



Any suggestions on what might be causing this, and/or what the fix
might be?

Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV5OvEAAoJEAHN/EbZ1y06BxwP/0O0IBN7wkTlkYtoXjB+6+pn
CnG+aVOaj+aqywqKSp2oJFchpaYTtj9GRzDzA8pOabnXihU43xy8I3msFxGBKeDu
lDyV4gW7Ijy5FBxM3e1xjZHiJXoYxkTURevVwOy+hkAz8RK8Z2kIG8SgnCRJCBW9
jacASbbUqBrTaokSY+3x/wr9C5V2Swz3CP14r8N52CeH+8gqoQeyomNR5EBYkwtQ
zPPwRU9EGi6DYy0tNA8ATjFYhc/A0DNc5Gn1UdgIRQkFobxwopc6WBb+RpEc57ko
HbBF8uIROOml3MPKRheTNFBLkkgeQxRaEuCXU/f7oRJDYbI1uqxh/jQDhzHbO0lo
p2RL3Ysq0MjJYIedJpSLWlB36fcl1UORDXoyD4F2ZNvOMXxf/8uOzF7gfFpC3nBk
PA/RZw9obqeB6ouTi1uLDAwExoGL7xE157h0irYKNJElpRUnF98of7s990MUjJgz
jLvb73ErHsjFB7xlRmZIIIi1p4ACOdLZQRk0Ll5t1rUHn8tD57Uv9nrYa3UC3e+b
l8+4YDNZ+TC441Kh6/GjyQT7b2itnq1mfDYBiP66ul3sSwtNgIpT0/6dlOt4wjI3
Vb3PKAm3lIHSeBe2VG/WC6qhB0REbU3gdJTfpty++Oy3mZpPPz3rbxMbseC6qf1A
h90eCfV+dwJiPffNEPDD
=FO7y
-----END PGP SIGNATURE-----

[Jeremy Rand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/01/2015 12:05 AM, Jeremy Rand wrote:
> Hello,
>
> I'm having trouble installing nokogiri on Debian Jessie.
> (Specifically, on a Qubes 3 Whonix 11 template, but I doubt that
> there's anything particularly unique about that setup.) Here's a
> paste of what gets displayed in the terminal:
>

[snip]

>
>
>
> Any suggestions on what might be causing this, and/or what the fix
> might be?
>
> Thanks.
>

Interestingly, the following installs successfully:

sudo gem install nokogiri -- --use-system-libraries

Maybe that helps track down the issue.

Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV5O3FAAoJEAHN/EbZ1y06IBcQAI6Y35B32fS/YOeDKg8Bk+UB
0tC3dp+EULGSr3VjSaf9F07HNfOjDYIs/Yr5bO1kx6VbStMp9eb0infDgINNHoyC
rYpTYpdKdaIk5fYinux5HpVKLMhvBBR12QaGToXU59QqYH3Zqe+DnLvwqV0x2vUP
bYmFKhxGt+zthjutp/WugQoYjFrhaPU/yFUdWn64OhY5sbYNOlKvy1OoMNOQeIR4
H4wuZvpY8Yx573pZgrSXpfq6k22+qXEP0h9TCzNG9Zmvv0RGPdBEjsjPwlXummId
BewVbFPe0xVnLLWZMW89Quj14sz+Bbg021p6cDEys9WqwWSTfGzBNU8ze+6Xi/6o
0JP55B6RIHkkfnKHihYPLO1QgsiyhXN0LhNyzhbjDagpcmAPZnwVh1/CA1vj8IEz
C9SFIbB4z0K3u7FDOJmAQRyRog8O1xYRGsun1roCiU7YA2LnHoDlYHoZ+lXgmHSP
WZWemqUzzKF5ZnyKN+H3rCif995Prxv6n8wmBT/8kOActhfTDbTM7Cs+LXCqiyii
zoVNU/3lNYOzM+1ZoZMsOfhZVFYmLdXcozaI225AVQJGsRrg2MYjeQTRSuFv7mD4
2JhtFzJE9Oqy69wQCEV92fFgxOFe0NyQpSc0xyDMfl4bBabHIV42rc/pWoC+ptvQ
SZqaW9R894ZLFndxP4FG
=xI18
-----END PGP SIGNATURE-----

[Mike Dalessio]

Hmm, looks like you're using a prerelease of mini_portile. Can you try with v0.6.2 or earlier of mini_portile?

-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "nokogiri-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nokogiri-tal...@googlegroups.com.
To post to this group, send email to nokogi...@googlegroups.com.
Visit this group at http://groups.google.com/group/nokogiri-talk.
For more options, visit https://groups.google.com/d/optout.

[Mike Dalessio]

I've confirmed this behavior when you use mini_portile 0.7.0.rc2 with nokogiri 1.6.6.2. However, nokogiri 1.6.6.2's dependency on mini_portile is "~> 0.6.0" which means specifically NOT mini_portile 0.7.x. You're using an unsupported combination of gems.

I'll encourage you to use `bundler` or some other package manager to make sure you're using appropriate versions of your dependencies.

[Lars Kanis]

Hi all,

it seems that this issue is a bit more tricky. I verified that the
installation of any nokogiri version between 1.6 and 1.6.6.2 fails, as
soon a mini_portile-0.7.0.rc2 is installed for the given Ruby version.

This is because we define mini_portile ~>0.6.0 as a runtime dependency
of nokogiri, but make use of it at install time. So rubygems takes care,
that the right version is loaded at runtime (when it is no longer of
interest), but for the run of extconf.rb, it is always the latest
mini_portile version that is loaded. This is even the case, when
installed per bundler.

Now we can enforce the dependency equally in extconf.rb by changing to
gem "mini_portile", "~> 0.7.0"
require "mini_portile"

However this will still break already released nokogiri versions. So the
only way to get a backward compatible behaviour, I currently see, is to
change the entry point of mini_portile in 0.7.0. That means, we rename
mini_portile.rb, so that require "mini_portile" always loads a version
smaller than 0.7.0. If we want to use some newer version of mini_portile
we need to require "mini_portile_0_7" or something like. Or we change
the gem name in equal measure.

What do you think?

--
Regards,
Lars

[Mike Dalessio]

Lars,

What if we made the new string handling a option passed into `MiniPortile.new`?

We could default the option to "old style" (which would take some work), but allow us to opt into the new behavior in Nokogiri 1.6.7 without breaking previous versions of Nokogiri. Then, in a later version of mini_portile, we could default it to "new style", with deprecation warnings, etc.

I'll take a look at how much work this would be.

[Lars Kanis]

Am 03.09.2015 um 14:38 schrieb Mike Dalessio:
> What if we made the new string handling a option passed into
> `MiniPortile.new`?
>
> We could default the option to "old style" (which would take some
> work), but allow us to opt into the new behavior in Nokogiri 1.6.7
> without breaking previous versions of Nokogiri. Then, in a later
> version of mini_portile, we could default it to "new style", with
> deprecation warnings, etc.

Of course, this is an option. What I dislike about it, is that we break
the installation of already released gems, if they derive from
MiniPortile in a way, that is somehow incompatible to our latest
changes. And we will definitely break the install of some other gems
(like nokogiri-1.6.0 to 1.6.6.2), at that point in time, when we change
to the "new style" as the default.

I already checked if there is a way to find out, if some kind of 'gem
"mini_portile", "~>version"' call was issued before the 'require
"mini_portile"' call. This way we could change the library behaviour
accordingly and print a warning, if the gem version constraint wasn't
set. Unfortunately there seems to be no proper way to query for this
information.

In any case we should strongly recommend to set a gem version constraint
within extconf.rb.

--
Regards,
Lars

[Mike Dalessio]

I've just shipped mini_portile 0.7.0.rc3, which introduces an option to turn on or off "unescaping" of escaped strings:

https://github.com/flavorjones/mini_portile/commit/55254730639128e4605b2cb4f530e2445eb7f604

By default, it will unescape strings, which works for both older versions of Nokogiri as well as the current 1.6.7.rc2.

I'm happy to consider other options as well, but I wanted to get a fix out quickly, as this was affecting people who happened to have mini_portile 0.7.0.rc2 installed on their system.

--
Regards,
Lars

[Mike Dalessio]

I've just cut mini_portile 0.7.0.rc4 which should be backwards-compatible with mini_portile 0.6.x on all platforms (phew).

Any objections to this shipping this version as 0.7.0 final? Lars?

(Nokogiri 1.6.7.rc3 will be released with an updated dependency as soon as the build goes green.)

[Lars Kanis]

Hi Mike!

Am 04.09.2015 um 17:50 schrieb Mike Dalessio:
> Any objections to this shipping this version as 0.7.0 final? Lars?

To be honest - yes I have. There are at least a couple of gems that
depend on MiniPortile, right now:
https://libraries.io/rubygems/mini_portile/dependents

Although mini-portile-0.7.0-rc4 is *mostly* compatible to the previous
versions, now, I wouldn't vouch for not breaking the installation of any
of these already released gems (maybe on some particular circumstances
at least). And on the other hand, we are forced to keep full backward
compatibility forever, as long as we don't want to break the gems of
other authors.

So, if we don't want to break the work of other gem authors, we need to
make a clear separation of the code of the major MiniPortile releases.
For the future this can be ensured by explicit recommending authors, to
place a gem version constraint into the extconf.rb file, like in PR #59.
However this step was by for not obviously in the past, so that it's
probably missing in the majority of the gems out there. Even more, I
guess, that it will take ages, until all gem authors will release new
gems with this version constraint inside.

The only way to get a clear separation, I was able to find, is to change
the lib/mini_portile.rb file to another name. So this makes the require
"mini_portile" statement to choose the old version, even if a newer one
is installed. We could change to "mini_portile2" or "mini_portile_0_7"
or whatever, but keeping the name "mini_portile" will sooner or later
disturb the installation of other gems.

So this is my (pessimistic) opinion to this question. I hope we can come
to an agreement nevertheless.

--
Regards,
Lars

[Mike Dalessio]

Lars, let's chat about it? Are you available to be in IRC at all tomorrow (Monday)? I'm on America/New_York time but have a holiday and so am very flexible.

[Lars Kanis]

Hi Mike,

I can not use IRC at work. Is it OK to use email? I'm available today and I'll try to answer quickly.

In the meanwhile I've added a note about the changed require-name: https://github.com/flavorjones/mini_portile/pull/60

[Mike Dalessio]

Hi Lars,

Sorry we couldn't make a realtime conversation work; I don't think email will suffice for us to quickly work through this discussion.

Before we make any decisions, I'd like to go through the mini_portile dependencies and check if there are any installation issues with 0.7.0.rc4. Admittedly this will be limited to only my particular installation of Linux, but a failure case would prove my proposal definitively inadequate, and then we can work through adoption of your proposal.

[Lars Kanis]

Before we make any decisions, I'd like to go through the mini_portile dependencies and check if there are any installation issues with 0.7.0.rc4. Admittedly this will be limited to only my particular installation of Linux, but a failure case would prove my proposal definitively inadequate, and then we can work through adoption of your proposal.

I don't think this is a good idea. I have 6 such gems (fxruby, glut, tiny_tds, osmesa and 2 closed source) and I don't want to get them broken. This is the type of checks we would need before each and every release of mini_portile in the future: Check each version of each already released gem with a dependency to mini_portile on every OS in every environment. Otherwise we risk to destroy the work of other people. This is what semantic versioning is made for. And my proposal is to enforce semantic versioning, even if used in the extconf file - nothing more.

In https://github.com/flavorjones/mini_portile/pull/60 I reverted your additions for unescaping strings. However, we could still leave this as an option, if you think so.

--

Regards,

Lars

[Mike Dalessio]

On Tue, Sep 8, 2015 at 10:36 AM, Lars Kanis <la...@greiz-reinsdorf.de> wrote:

Before we make any decisions, I'd like to go through the mini_portile dependencies and check if there are any installation issues with 0.7.0.rc4. Admittedly this will be limited to only my particular installation of Linux, but a failure case would prove my proposal definitively inadequate, and then we can work through adoption of your proposal.

I don't think this is a good idea.

I don't see how it's possible for it to be a bad idea to learn more about the problem space.

 

I have 6 such gems (fxruby, glut, tiny_tds, osmesa and 2 closed source) and I don't want to get them broken. This is the type of checks we would need before each and every release of mini_portile in the future: Check each version of each already released gem with a dependency to mini_portile on every OS in every environment. Otherwise we risk to destroy the work of other people. This is what semantic versioning is made for. And my proposal is to enforce semantic versioning, even if used in the extconf file - nothing more.

In https://github.com/flavorjones/mini_portile/pull/60 I reverted your additions for unescaping strings. However, we could still leave this as an option, if you think so.

--

Regards,

Lars

[Lars Kanis]

>>
>> I don't think this is a good idea.
>
>
> I don't see how it's possible for it to be a bad idea to learn more about the problem space.

Sure - it was more about making a decision based on the installation of a particular gem.

--
Regards,
Lars

[Mike Dalessio]

Just to communicate what's going on to nokogiri-talk: Lars and I decided to bump the gem name of mini_portile to mini_portile2 for the backwards-incompatible reasons laid out previously in this thread. mini_portile 0.6.2 will likely be the final stable release for that gem.

I'll be releasing mini_portile2 v2.0.0.rc1, and nokogiri 1.6.7.rc4 which will depend on it, sometime today. These *should* be the last release candidates of each, unless something else unforeseen pops up.

--
Regards,
Lars

--