I am trying to build Ruby from source for Windows, and there doesn't seem to be very good documentation on how I can get a local build of OpenSSL to hook up to my ruby build. Is there some way I should be copying in DLLs/EXEs/whatever in order to build a version of Ruby with the latest OpenSSL version (like 1.0.1r or something)?
So yeah, this is both a simple and hard question.
First off, I'm assuming you're using the RubyInstaller project and not compiling with MSVC. If you are using MSVC then some of this may be useful, but overall not.
Just for reference this is the code that actually configures which version to use.
The next piece of valuable information, the environment RubyInstaller uses to build Ruby is based off of rubenvb's mingw64 builds(Version 4.7.2 in this case) and cherry picked MSYS tools. The compiler is important because issues have been known to happen using libraries that aren't built by the same compiler. I don't actually know much about that area.
RubyInstaller tries to avoid this problem by providing binaries built with the DevKit with the OpenKnapsack Project. The openssl libraries are downloaded from there for RubyInstaller builds. If there is a binary you want then you can upload a working recipe to the knapsack-recipes repo and it will be built in 32 and 64-bit flavors and uploaded. I do this manually. -sad face-
So, the simple part is you can take any of those binaries you want and just drop the DLL into the Ruby bin folder and it will link and use that DLL. But the version that Ruby is compiled with is a hard-coded constant and won't change even though you have a new version of the DLL.
The hard part is that if there isn't a recipe for the version you want in the knapsack-recipes repo you have to make one and submit a pull request or find/build the version yourself. And then if you really want to have the correct version hard coded in Ruby you have to change the config in the rubyinstaller project and then build Ruby yourself using a command like:
> rake ruby21 DKVER=mingw64-32-4.7.2 #32-bit
> rake ruby21 DKVER=mingw64-64-4.7.2 #64-bit
Related
TLS 1.0 and 1.1 are being deprecated and I want to make certain that it is not going to be used anywhere. I am looking at a large number of repositories (with very little previous Ruby gem experience) and I don't see any direct references to TLS, but, I do see some references to openssl.
There is a helpful page concerning TLS deprecation: https://blog.rubygems.org/2018/02/24/tls-10-and-11-deprecation-notice.html
It contains a command: curl -sL https://git.io/vQhWq | ruby
While I can run this command locally against my various versions of installed (J)Ruby, I don't really know if this means anything relative to a large production environment.
Is the version of openssl always determined by the version of ruby in use, or am I missing something? Even if my local install of ruby 2.5.5 indicates openssl 1.1.1g and 1.1.1i (compiled and loaded versions, respectively) and these versions of OpenSSL do not support TLS versions below 1.2, could the prod environment could still be using ruby 2.5.5 with TLS below 1.2?
First, it is important to understand the parts involved:
Ruby (the language) includes the openssl extension. The extension is compiled and linked against an openssl library. You can, I believe, also install the openssl extension as a gem in which case the gem's extension will be compiled and linked against an openssl library, though this configuration is very rare (people would usually recompile all of Ruby to rebuild their openssl extension).
In theory, whenever the openssl extension is compiled it can reference a distinct copy of openssl library. When the extension is loaded at runtime it can reference a distinct copy of the library also, and not necessarily the same one that the extension was compiled against.
MOST Ruby installations utilize the systemwide openssl library, and there is only one library in play regardless of how many Ruby versions are built and installed. But some installations have multiple openssl libraries involved, for example when the system library is too old or too new for the particular application's desires.
Now, the version (as in version number) of Ruby only matters to the extent that each version ships a particular version of the openssl extension. This mostly makes a difference at compile time, in that old Rubies don't build with recent openssls. Assuming a typical Ruby installation which includes the openssl extension, once the extension is built it'll generally work with the same version of openssl library that was used during compilation or newer.
What I suggest you do is:
Find all OpenSSL installations on the system you are analyzing, find out how they are configured, check for appropriate/inappropriate configuration.
Find all OpenSSL extension copies (openssl.so) the system you are analyzing and figure out what openssl libraries they are linked against.
Note that the version number of Ruby, as well as how many Ruby installations you have, is only irrelevant insofar as this gets you to the respective installed openssl extensions.
Which OpenSSL library is used can be overridden at runtime (LD_LIBRARY_PATH, etc.) therefore only looking at defaults is insufficient if you want to be thorough.
JRuby has its own openssl extension which I assume uses Java's SSL functionality. To verify this, create a VM/docker container, uninstall everything openssl-related from there, install JRuby and check TLS functionality. If JRuby does not use OpenSSL library you would need to work out what TLS functionality your installed Java runtime(s) provide.
I didn't get any windows installer to install ruby 2.1.2. The only resource I found is a tar/zip file that is available at https://www.ruby-lang.org/en/downloads/.
I have no idea how to install this , anyone provide some suggestions how to install 2.1.2 version of ruby.
I have been able to crack the zlib nut (for Windows 8.1 -- see below), but I'm still struggling with openssl, readline, etc... I find it amazing that this documentation does not seem to be easily found, and that some experts/respondents advise using the 2.0 installer without considering that users are fighting this fight because we need the 2.1.2 functionality.
I downloaded zlib128-dll.zip from http://zlib.net and unzipped the contents to a directory (e.g., c:\zlib).
Then following some hints from this post (https://www.ruby-forum.com/topic/4421852), I created these dirs off of my c:\ruby-build\usr directory:
zlib
zlib\include
zlib\lib
Then I copied some files from my C:\zlib directories to my c:\ruby-build\usr directories:
*.h files (both) from C:\zlib\include to c:\ruby-build\usr\zlib\include
zdll.lib from C:\zlib\lib to c:\ruby-build\usr\zlib\lib.
zlib1.dll *AS* zlib.dll from C:\zlib to both c:\ruby-build\usr\zlib\lib and c:\ruby-build\usr\bin
(not sure which one or both are necessary).
Then from a VS 2012 Native Tools Command Window, I naviagted to C:\ruby-2.1.2\ext\zlib and executed:
\ruby-build\usr\bin\ruby extconf.rb --with-zlib-dir=c:/ruby-build/usr/zlib
Then nmake, followed by nmake install, and voila, I zlib was finally installed.
Let me know if you any questions about my steps.
The project Ruby Installer has published Ruby 2.1.3 for Windows (32 and 64 bits versions) on their download page:
http://rubyinstaller.org/downloads/
You will also find there a new build for Ruby 2.0 (p576).
Although they didn´t updated their news page yet.
The standard way to install Ruby on Windows is with Ruby Installer. However, due to some bugs/regressions in Ruby, there has been some hold up creating an installer for Ruby 2.1 on Windows. To get Ruby 2.1 on Windows, you'll likely have to compile from source.
That's a good question. It seems that 2.1.2 is not easily available on bitnami or ruby installer.
Check this out.
If it's not worth the pain or if you don't explicitly need the features of 2.1.2, I would recommend just installing 2.0.x's stable release.
Please let me know if you have any questions!
I am using svn_wc.
It gives err as no such file to load -- svn/core (LoadError)
what to do?
The above answer is a link only answer and can become useless when the link is dead. Dumping the link contents here -
SVN 1.5.1 / Ruby bindings on Windows
Rather than messing around with compiling swig bindings etc:
Download the ruby bindings from the svn site: (http://subversion.tigris.org/files/documents/15/43245/svn-win32-1.5.1_rb.zip)
From the zip - copy ruby\lib\svn into c:\ruby\lib\ruby\site_ruby\1.8\svn
From the zip – copy ruby\ext\svn\ext into c:\ruby\lib\ruby\site_ruby\1.8\svn\ext
copy libeay32.dll and ssleay32.dll from your subversion 1.5 directory into c:\ruby\bin
run irb and test with: require ‘svn/core’
Where can I find updated binaries? I've looked around on the
Subversion site, but there seems to be no link.
They are available on the subversion site here: svn-win32-1.5.5_rb.zip
If you go to the subversion site and select windows binaries for
apache 2.2 you will see the list.
I just over-wrote the two DLL files (libeay32 and ssleay32) that came
with my ruby 1.8.6 installation with the two that came with my svn
1.5.5 installation. (Yes, I saved the originals.)This was necessary to passing the "require 'svn/core'" test, but is this likely to have
broken something within ruby?
Hey Ramon, i'd hope not but you never know :) The dll's are OpenSSL
libraries so if you see any weird behaviour when using any ssl related
functionality in ruby, that'd probably be the culprit
Ruby can't find svn/core in your installation, if you look at the github page for svn_wc the requirements are listed as:
Requires that the Subversion (SWIG) Ruby Bindings are installed
Which is much easier to do on Linux and OSX than on Windows
I need to know if it is possible to compile the best and newest package in an old, ancient system. Why? Well I'm limited at my company: I need to develop an application in an old Debian 3.0 server and I would prefer to use newer software to accomplish my task. Unfortunately, I'm not allowed to upgrade nor install any package.
Specifically, I want to parse XML files comfortably using xmlstarlet to do so. This server doesn't have it installed; if I download an older version of xmlstarlet supported by the system it's too old that I just lost the functionality I need. It just has three dependencies: libc6, libxml2 and libxslt1.1 (which are installed but are too ancient for a newer version of xmlstarlet)
So the question is: is there a way I can download this package and its dependencies (I think they are few and simple) and somehow compile them to work locally (not necessarily on the system's path, just in a working directory) without affecting in any way the legacy packages of the same name?
This system doesn't has PEAR either, nor PHP5, nor xmllint and I want to avoid coding in PHP4 to parse these XMLs. I really would like to work with xmlstarlet.
The answer to How to specify non-default shared-library path in GCC Linux? Getting "error while loading shared libraries" when running looks like it should work fine.
Or you could try static linking:
./configure --enable-static-libs
I am currently using ubuntu 9.10 with the glibc version 2.11.1-0,
well i am doing a project, that i want to test with the another version of glibc that is 2.5-58, i wanted to know following things regarding this:
How to compile the version of 2.5-58, however keeping the previous version?
How to link the existing programs with the binaries of newer version of glibc?
I would be highly obliged if anybody can help me!!!
Thanks
If you want to manually compile another version of glibc, then I suggest you configuring (./configure script run) it with --prefix option to install not to /lib, /usr/lib but to /home/mehul/glibc2.5.58test/lib and /home/mehul/glibc2.5.58test/usr/lib
But compiling of glibc is not very easy thing, so another way is to get glibc 2.5-58 in compiled form from other linux and manually copy it to some subdirectory. Then you can override library search path of gcc and recompile your lib with libc from subdirectory.
Or you can use LD_LIBRARY_PATH to override library search path of compiled binary to use older glibc like this:
$ LD_LIBRARY_PATH=/home/mehul/glibc2.5.58test/lib /path/to/your/application
If you know that that version of libc is used in an older ditribution, you could install that distribution in a chroot/scratchbox/kvm/qemu/livecd or other such system for testing and building. Or there may be some other build farm type solution. Then you'll have an authentic system to test on that will not mess up your up to date one. It'll also be repeatable if you keep that system image.
If this isn't about a specific older release, why on earth would you want to test against a specific very old libc?