Nokogiri: Versenden Sie vorkompilierte Gems für Linux

Bundler-2.2.0 behebt die Probleme mit binären Edelsteinen. Ich habe schon ein bisschen mit der verbesserten Multiplattform-Unterstützung unter Windows gespielt. Ich habe Nokogiri bisher nicht unter Linux getestet, aber eine Vorabversion von Nokogiri wird ein einfaches Testen ermöglichen.

Bezüglich Alpine Linux (auch bekannt als musl libc) habe ich etwas recherchiert und herausgefunden, dass sprintf() nicht richtig funktioniert, aber Segfaults, sobald irgendwelche Argumente verwendet werden. Es wird nur einmal verwendet hier und können leicht ersetzt bekommen strcat() / strcpy() .

Nachdem der Sprintf-Segfault behoben wurde, gibt es einen fehlgeschlagenen Testfall auf Alpine mit binärem Gem:

Nokogiri::HTML::TestDocumentEncoding#test_encoding_without_charset:
ArgumentError: invalid byte sequence in UTF-8
    /comcard/nokogiri/test/html/test_document_encoding.rb:26:in `test_encoding_without_charset'

Der Testfall ist mit der Codierung Shift_JIS , schlägt jedoch mit cp932 fehl, obwohl sie größtenteils austauschbar sind. Ich werde versuchen, die Ursache zu finden.

@larskanis Ich möchte nur bestätigen: Sie denken, ich sollte einen RC für vorkompiliertes Linux versenden? Das kann ich am Montag machen, wenn ja.

Ich kann Alpine zu den CI-Pipelines hinzufügen - das ist möglicherweise der einfachste Weg, um festzustellen, ob etwas defekt ist. Das werde ich am nächsten Tag oder so versuchen.

@larskanis Sie sind da draußen! https://twitter.com/flavorjones/status/1224334774753513473

Einige Rückmeldungen zu vorkompilierten Binärdateien im Allgemeinen, nicht zu Nokogiri.

Auf dem Papier sind vorkompilierte Binärdateien großartig, da sie viel schneller zu installieren sind, aber sie sind ein großer Schmerz, wenn eine neue Ruby-Version veröffentlicht wird.

Ich hatte gerade dieses Problem mit den Edelsteinen grpc und google-protobuf . Ich wollte die 2.7.0 RCs ausprobieren, konnte aber nicht, weil vorkompilierte Edelsteine ​​eine höhere Anforderung an Ruby-Versionen stellen.

Zum Beispiel hat https://rubygems.org/gems/nokogiri/versions/1.11.0.rc1-x86-linux :

REQUIRED RUBY VERSION:
>= 2.4, < 2.8.DEV

Stellen wir uns also vor, ich verwende diese Version in meiner App und versuche bis Ende 2020, die Ruby 3 RCs (oder die 3.0-Version im Januar 2021) zu testen.

Ich kann wegen dieser Ruby-Versionsanforderung nicht mehr bündeln. Theoretisch könnte der Bundler auf das Quell-Gem zurückgreifen (https://rubygems.org/gems/nokogiri/versions/1.11.0.rc1), aber es gibt nur ein globales Flag, das nicht sehr praktisch ist.

Aaron hatte das gleiche Problem mit grpc: https://twitter.com/tenderlove/status/1222937689751605248

Mir ist klar, dass dies eher ein Bundler-Feedback als ein Nokogiri-Feedback ist, aber meine persönliche Meinung ist, dass Bundler / Rubygems / was auch immer verbessert werden müsste, bevor beliebte Edelsteine ​​​​mit vorkompilierten Binärdateien beginnen.

@casperisfine Danke für das Feedback. Dies sollte in Bundler 2.2 behandelt werden, siehe https://github.com/rubygems/bundler/pull/7522 (oben erwähnt) für mehr Kontext.

🤦‍♂ Entschuldigung, ich habe die Problembeschreibung viel zu schnell gelesen. Schön zu hören, dass das bald kein Problem mehr sein wird.

Insgesamt ist der beste Weg, nokogiri auf Fedora zu installieren, über dnf install rubygem-nokogiri und der Fedora-Benutzer muss sich nicht darum kümmern.

Trotzdem ist die Laufzeitabhängigkeit von mini_portile2 bei vorgefertigten Paketen ärgerlich.

@voxik Danke für deine Kommentare!

Kann ich Sie in Bezug auf die Installationsanweisungen von Fedora bitten, eine PR zu dieser Datei im Dokumentationsrepo zu senden?

Und – du hast recht! Wir sollten keine Laufzeitabhängigkeit von mini_portile2 für vorgefertigte Pakete haben. Ich habe # 1991 geöffnet, um das in einem zukünftigen RC zu beheben.

Ich fange gerade an, die Dinge zu untersuchen, aber ich sehe ein Verhalten, das darauf hindeutet, dass die Gem-Installation --use-system-libraries und env["NOKOGIRI_USE_SYSTEM_LIBRARIES"] = "true" ignoriert und stattdessen die vorkompilierten Linux-Fat Gems installiert. Es wird einige Zeit dauern, bis ich es zu einem nützlichen Minimalbeispiel zusammengefasst habe, das jedoch nicht eng an unser gesamtes Build-System gekoppelt ist. Ich bin mir nicht sicher, ob dies etwas bekannt ist oder nicht.

@lamont-granquist Das von Ihnen beschriebene Verhalten wird erwartet. --use-system-libraries und NOKOGIRI_USE_SYSTEM_LIBRARIES sind nur Funktionen des Gems platform=ruby. Die binären Gems können nicht mit der System-Libxml2 verlinken, haben aber immer libxml2 und libxslt eingebaut.

Ja, weiß jemand, wie man die ruby_platform auf einem gem install überschreibt, um den fetten Edelstein zurückzubekommen? Mein Google-Fu hat mich gestern ziemlich stark im Stich gelassen. Ich kann mich nicht erinnern, ob das machbar ist oder nicht oder ob Sie das Gem nur direkt herunterladen und dann von der Festplatte installieren müssen.

@ lamont-granquist Versuchen Sie gem install --platform=ruby --pre nokogiri

@lamont-granquist Können Sie mir helfen zu verstehen, warum Sie das Gem platform=ruby möchten, wenn eine vorkompilierte Version der Bibliotheken verfügbar ist?

Danke für den Tipp mit dem Befehl.

Wir bauen und liefern unseren eigenen vorkompilierten Ruby an einem nicht standardmäßigen Ort und verwenden feste rpaths in der Binärdatei (wir bauen auch libxml2 + libxslt und akzeptieren, dass wir vollständig für die CVEs in diesen verantwortlich sind und darauf reagieren müssen). Darüber hinaus verlinkt unsere Libruby mit unserer eigenen Version mehrerer anderer Bibliotheken wie openssl (mehr Spaß CVEs) und libz und wenn überhaupt, wird, wenn versucht wird, gegen Libruby zu verlinken, gegen die Systemversionen gelinkt, was zu Linker-Problemen und schweren Fehlern führen kann. Und die Systemversionen, die wir in Betracht ziehen müssen, gehen auf RHEL6 für Linux zurück und umfassen auch Solaris 11, AIX, FreeBSD und Mac -- unsere Ruby-Version bleibt auf dem neuesten Stand, so dass wir zB Ruby 2.7.0 auf RHEL6 konsistent ausliefern können und eine aktuelle libz/openssl/etc haben (und dann keine Segfaults debuggen müssen, die vor mehr als 6 Jahren im Ruby-Kern behoben wurden und die noch auf RHEL6 existieren).

Wir haben ein Skript zur Integritätsprüfung, das alle Bibliotheken prüft, die in unseren Build einfließen, und eine Liste mit Verstößen ausspuckt. Für diese aktuelle Vorabversion von nokogiri sehen die relevanten Teile des Berichts so aus:

    --> /opt/chef/embedded/lib/ruby/gems/2.7.0/gems/nokogiri-1.11.0.rc1-x86_64-linux/lib/nokogiri/nokogiri.so
    DEPENDS ON: libruby.so.2.5
      COUNT: 1
      PROVIDED BY: not found
      FAILED BECAUSE: Unresolved dependency
    --> /opt/chef/embedded/lib/ruby/gems/2.7.0/gems/nokogiri-1.11.0.rc1-x86_64-linux/lib/nokogiri/nokogiri.so
    DEPENDS ON: libz.so.1
      COUNT: 1
      PROVIDED BY: /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa9fcba3000)
      FAILED BECAUSE: Unsafe dependency

Daher wird libz als "unsicher" angesehen, da es von der Version in /opt/chef/embedded/lib/libz* die unsere Libruby verlinkt ist. Und dann kann es nicht einmal die Libruby finden, weil das vorgefertigte nokogiri.so nicht den richtigen RPATH hat, um die benötigten /opt/chef/embedded/lib/libruby* zu finden. Wir verwenden /etc/ld.so.conf nicht, wenn ich mich recht erinnere, weil chef das Werkzeug ist, das diese Datei verwalten muss, und wenn Sie das vermasseln, was chef vermasselt, landen Sie in einem Huhn-und- egg-Szenario, daher bevorzugen wir hartcodierte rpaths in den Binärdateien.

Ich denke, der TL;DR ist, dass wir hier wie der 0,0001% Anwendungsfall sind.

Sie können jedoch feststellen, dass Sie Fehlerberichte von Chef-Benutzern erhalten, die versuchen, die Nokogiri-Version in ihren Chef-Paketen selbst zu aktualisieren, nehme ich an. Der Sinn meiner Vorgehensweise bei unseren Client-Builds besteht darin, dass sie dies nicht müssen, aber die Leute bleiben bei alten Client-Versionen hängen und versuchen möglicherweise, sich selbst zu aktualisieren. Ich sehe heute Morgen jedoch keinen einfachen Weg, das zu umgehen (von Natur aus kann ich nichts patchen, um ihr Leben einfacher zu machen, wenn sie auf mehr als 5 Jahre alten Versionen des Clients sind, und es scheint der fette Linux-Gem-Ansatz zu sein ist für den Anwendungsfall von 99% wesentlich besser, sodass diesen Leuten nur gesagt werden muss, dass sie die Plattform überschreiben – oder einfach den Chef aktualisieren). Wir versenden bereits seit Jahren vorgefertigte Nokogiri, also machen es hoffentlich nicht viele Leute selbst.

@lamont-granquist Wow, danke für diesen Kontext, ich schätze die Sorgfalt, die Sie in Ihre Umgebung investieren.

Sind Sie in der Lage, das Verhalten des Bundlers bei der (standardmäßigen) Installation nativer Gems zu umgehen? Es kann hilfreich sein, den Bundler-Konfigurationsschlüssel auf force_ruby_platform (siehe https://bundler.io/v1.15/bundle_config.html), damit native Versionen von Gems ignoriert werden. @larskanis hat möglicherweise mehr Einblick in die

Das kann später hilfreich sein. Für den Client ist nokogiri ein angehängtes Extra, das wir 'gem install'. Die Bundler-Optimierungen können jedoch für Chef Workstation (ChefDK) nützlich sein, wo Nokogiri von der von uns ausgelieferten Software verwendet wird und daher in dem von uns generierten Bundle enthalten ist. Das ist heute einfach nicht die Aufgabe und ich habe mir noch gar nicht so viele Gedanken gemacht.

Ja, es sieht so aus, als ob wir bundle install dort sind und erwarten, dass dies die env["NOKOGIRI_USE_SYSTEM_LIBRARIES"] = "true" Einstellung übernimmt, also wird das auch etwas Arbeit erfordern.

@lamont-granquist Um es klar zu sagen, Nokogiris "Systembibliotheken" -Flags funktionieren immer noch, aber nur während der Installation des ruby Plattform-Gems. Möglicherweise möchten Sie Folgendes ausführen:

NOKOGIRI_USE_SYSTEM_LIBRARIES=t gem install ---platform=ruby nokogiri

oder das Äquivalent:

gem install --platform=ruby nokogiri -- --use-system-libraries

Dieser Befehl funktioniert mit früheren und zukünftigen Nokogiri-Versionen, um Nokogiri aus dem Quellcode gegen lokale Systembibliotheken zu kompilieren.

Yep, schon getan, was feste Builds. Backcompat scheint wie erwartet zu funktionieren.

Um besser zu verstehen, wie funktioniert das vorkompilierte Nokogiri-Juwel auf Alpine, das Musl verwendet?

Für den Kontext hatte das sassc-Gem auch vorkompilierte Linux-Gems, aber sie wurden aufgrund dieser musl/glibc-Nichtübereinstimmung in https://github.com/sass/sassc-ruby/pull/145 entfernt , was es leider zu einem sehr langsamen Juwel macht zu installieren: https://github.com/sass/sassc-ruby/issues/189

@eregon Bitte https://github.com/sparklemotion/nokogiri/pull/1990 für Informationen zur Unterstützung der Musl.

@flavorjones Vielen Dank für den Link, aber meine Frage bezog sich eher darauf, wie das binäre Nokogiri-Gem auf Alpine funktioniert, da ich davon ausgegangen bin, dass es gegen glibc vorkompiliert wurde? Enthält es statisch glibc?

Nach meinem Verständnis funktioniert die Verwendung einer Binärdatei, die gegen Glibc auf Alpine kompiliert wurde, nicht, ohne ein zusätzliches libc6-compat Paket zu installieren (https://github.com/sass/sassc-ruby/issues/141#issuecomment-522821096). Vielleicht ist das akzeptabel, ich weiß es nicht, aber es schien einige Leute in dieser Angelegenheit zu überraschen.
Und RubyGems scheint nicht in der Lage zu sein, zu erkennen, welche libc verwendet wird/um ein binäres Gem pro libc zu haben.

@eregon Im master nur auf Alpine ohne Kompatibilitätsschicht. Siehe a3d9438 für einen Commit, der notwendig war, um unsere Verwendung von libc auf das zu beschränken, was ABI-kompatibel mit musl . Siehe auch https://ci.nokogiri.org/teams/nokogiri-core/pipelines/nokogiri/jobs/cruby-native-gem-test, um zu zeigen, dass das native Gem installiert wird und alle Tests auf Alpine besteht.

(bearbeitet mit aktualisierter CI-URL)

Hallo zusammen, ich bin Neuling in Ruby und fange an, Schienen zu installieren, und ich bekomme sehr Fehler und brauche Hilfe.
Ich habe einige Probleme gelesen, aber mein Fehler wurde nicht behoben.
gem install --prerelease
FEHLER: Beim Ausführen von gem ... (Gem::CommandLineError)
Bitte geben Sie mindestens einen Gem-Namen an (z. B. Gem-Build GEMNAME)
und
Edelstein installieren Schienen
FEHLER: Fehler beim Installieren von Schienen:
Die letzte Version von nokogiri (>= 1.6) zur Unterstützung von Ruby & RubyGems war 1.10.9. Versuchen Sie es mit gem install nokogiri -v 1.10.9 installieren und führen Sie dann den aktuellen Befehl erneut aus
nokogiri erfordert Ruby-Version >= 2.3, < 2.7.dev. Die aktuelle Ruby-Version ist 2.7.0.0.
und
gem install nokogiri --platform=ruby -- --use-system-libraries
PATH für MSYS/MINGW vorübergehend verbessern...
Erstellen nativer Erweiterungen mit: '--use-system-libraries'
Das kann etwas dauern...
FEHLER: Fehler bei der Installation von nokogiri:
FEHLER: Fehler beim Erstellen der nativen Gem-Erweiterung.

current directory: A:/*/install_ruby/Ruby27-x64/lib/ruby/gems/2.7.0/gems/nokogiri-1.10.9/ext/nokogiri

A:/ \ */install_ruby/Ruby27-x64/bin/ruby.exe -IA:/ \ */install_ruby/Ruby27-x64/lib/ruby/2.7.0 -r ./siteconf20200506-16216-1tc60ph.rb extconf. rb --use-system-libraries
prüfen, ob der C-Compiler akzeptiert ... ja
Erstellen von Nokogiri mit Systembibliotheken.
pkg-config konnte nicht verwendet werden, um libxml-2.0 zu finden
Bitte installieren Sie entweder pkg-config oder das pkg-config gem per

gem install pkg-config -v "~> 1.1"

pkg-config konnte nicht verwendet werden, um libxslt zu finden
Bitte installieren Sie entweder pkg-config oder das pkg-config gem per

gem install pkg-config -v "~> 1.1"

pkg-config konnte nicht verwendet werden, um libexslt zu finden
Bitte installieren Sie entweder pkg-config oder das pkg-config gem per

gem install pkg-config -v "~> 1.1"

FEHLER: Kann nicht erkennen, wo sich libxml2 auf Ihrem System befindet. Bitte stellen Sie sicher, dass pkg-config installiert ist.
* extconf.rb fehlgeschlagen *
Makefile konnte aus irgendeinem Grund nicht erstellt werden, wahrscheinlich fehlendes Notwendiges
Bibliotheken und/oder Header. Weitere Informationen finden Sie in der Datei mkmf.log. Du darfst
Konfigurationsoptionen benötigen.

Bereitgestellte Konfigurationsoptionen:
--with-opt-dir
--ohne-opt-dir
--with-opt-include
--Without-opt-include=${opt-dir}/include
--with-opt-lib
--Without-opt-lib=${opt-dir}/lib
--with-make-prog
--ohne-make-prog
--srcdir=.
--curdir
--ruby=A:/*/install_ruby/Ruby27-x64/bin/$(RUBY_BASE_NAME)
--Hilfe
--sauber
--use-system-libraries
--with-zlib-dir
--ohne-zlib-dir
--with-zlib-include
--Without-zlib-include=${zlib-dir}/include
--with-zlib-lib
--Without-zlib-lib=${zlib-dir}/lib
--with-xml2-dir
--ohne-xml2-dir
--with-xml2-include
--Without-xml2-include=${xml2-dir}/include
--with-xml2-lib
--Without-xml2-lib=${xml2-dir}/lib
--with-libxml-2.0-config
--ohne-libxml-2.0-config
--with-pkg-config
--ohne-pkg-config
--with-xslt-dir
--ohne-xslt-dir
--with-xslt-include
--Without-xslt-include=${xslt-dir}/include
--with-xslt-lib
--Without-xslt-lib=${xslt-dir}/lib
--with-libxslt-config
--ohne-libxslt-config
--with-exslt-dir
--ohne-exslt-dir
--with-exslt-include
--Without-exslt-include=${exslt-dir}/include
--with-exslt-lib
--Without-exslt-lib=${exslt-dir}/lib
--with-libexslt-config
--ohne-libexslt-config

Um zu sehen, warum diese Erweiterung nicht kompiliert werden konnte, überprüfen Sie bitte die mkmf.log, die Sie hier finden:

A:/*/install_ruby/Ruby27-x64/lib/ruby/gems/2.7.0/extensions/x64-mingw32/2.7.0/nokogiri-1.10.9/mkmf.log

extconf fehlgeschlagen, Exitcode 1

Gem-Dateien bleiben zur Überprüfung in A:/ .Ergebnisse in A:/ /install_ruby/Ruby27-x64/lib/ruby/gems/2.7.0/extensions/x64-mingw32/2.7.0/nokogiri-1.10.9/gem_make.out

Schließen dieses Problems. RC3 sollte in Kürze erscheinen, und ich verweise die Leute auf https://github.com/sparklemotion/nokogiri/issues/2075 , um Feedback zu geben.