You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using a non-default toolchain, so e.g. ld is available at gcc10-ld. For most gems with native code, they either use RbConfig to locate the toolchain (RbConfig::CONFIG['LD'] # => "gcc10-ld") or allow you to specify them as build arguments, e.g. gem install foo -- LD=gcc10-ld or bundle config build.foo LD=gcc10-ld. Nokogiri seems to pass along CC but won't pass along LD or AR to the libxml2 build.
Nokogiri will pass these along if they are defined in ENV, however.
The former would be preferred, because I can configure BUNDLE_BUILD__NOKOGIRI in the "user" bundler config file to correctly specify these. The latter requires someone who is bundle install'ing to specify the toolchain (which they should not need to know about).
I think that this would be a rather simple change to extconf.rb, but I'm not sure if this would be an accepted change or not.
The text was updated successfully, but these errors were encountered:
**What problem is this PR intended to solve?**
#3160
Note I also have branches that fix this on v1.16.x and v1.15.x, but I
wanted to make sure I actioned feedback in one place before I opened
additional MRs.
Also note that Nokogiri doesn't seem to honor variables passed as gem
configuration args, and I didn't add that here because I'm not entirely
sure what the "canonical" way to do this is with mkmf/mini_portile. In
other situations where I need to provide the toolchain
(rdkafka/karafka-rdkafka), there seems to be no special code to convert
`FOO=BAR` to an env var.
That said, it's not actually necessary in my case because using `AR` and
`LD` from `RbConfig` is sufficient. So one might say if you need to do
something different from that, maybe it's actually a good thing that you
would need to do `AR=x gem install nokogiri` rather than `gem install
nokogiri -- AR=x`. I can take a stab at making this work, though, if the
team thinks that both ways should work.
**Have you included adequate test coverage?**
N/A but I assume if it breaks the build in some configuration I didn't
test, GitHub Actions will be mad about it :).
**Does this change affect the behavior of either the C or the Java
implementations?**
No
Have you read and followed the installation tutorial at http://www.nokogiri.org/tutorials/installing_nokogiri.html?
We are using a non-default toolchain, so e.g.
ld
is available atgcc10-ld
. For most gems with native code, they either use RbConfig to locate the toolchain (RbConfig::CONFIG['LD'] # => "gcc10-ld"
) or allow you to specify them as build arguments, e.g.gem install foo -- LD=gcc10-ld
orbundle config build.foo LD=gcc10-ld
. Nokogiri seems to pass alongCC
but won't pass alongLD
orAR
to the libxml2 build.Nokogiri will pass these along if they are defined in ENV, however.
This results in this not working:
gem install --platform ruby nokogiri -- AR=gcc10-ar CC=gcc10-cc CXX=gcc10-c++ LD=gcc10-ld
But this works:
AR=gcc10-ar CC=gcc10-cc CXX=gcc10-c++ LD=gcc10-ld gem install --platform ruby nokogiri
The former would be preferred, because I can configure
BUNDLE_BUILD__NOKOGIRI
in the "user" bundler config file to correctly specify these. The latter requires someone who isbundle install
'ing to specify the toolchain (which they should not need to know about).I think that this would be a rather simple change to
extconf.rb
, but I'm not sure if this would be an accepted change or not.The text was updated successfully, but these errors were encountered: