I am looking for an migration from assembla to jira, For this i need Ruby version 2.4.1(windows exe file) but i am unable to find it anywhere still now . can anyone share me the link. so, i will be able to complete my task.
Go to https://rubyinstaller.org/downloads/archives/ and download the version you want.
These are specifically for Windows users.
Looks like the v2.4.1 exe is https://github.com/oneclick/rubyinstaller2/releases/download/2.4.1-2/rubyinstaller-2.4.1-2-x64.7z
But if you’re OK with v2.4.10 - and I’d highly recommend that you try it, it will have security and big fixes which 2.4.1 lacks and will likely be compatible with anything which requires 2.4.x - then download this exe https://github.com/oneclick/rubyinstaller2/releases/download/RubyInstaller-2.4.10-1/rubyinstaller-devkit-2.4.10-1-x64.exe which includes the basic gems you’ll also need.
Dear expert community,
I so often face problems that software will not compile or work because libraries (specifically .so files) are too new.
If I try to install the old library (apt-get on Ubuntu) I can get errors that it is "not installable" because of conflicts...
So following problems arise in my mind:
1) how to install old libraries/packages together with newer ones for example on Arch Linux or Ubuntu Linux ?
2) how to avoid conflicts: the older library should be used (linked) only with the "problematic old" software and/or if I specify this explicitly ?
3) how can I check with cmake, make or the autotools if a specific (old) library version is installed and in case not automatically get it and install it and use it without conflict with a newer version ?
Thank to any expert for a help
Linux package managers normally don't allow installing multiple versions of the same package. You have to install older versions yourself, by hand, from source, preferably to some private place like /usr/old-versions.
You link problematic software like this:
<link command> -L /usr/old-versions/lib -Wl,-rpath=/usr/old-versions/lib
and it automatically uses the old version of the library.
There is no way to do that automatically.
Note that you may need to compile against older versions of library headers too, not just link against old versions of the libraries.
I am trying to find a nice solution working on two different compass projects. One is based off Compass using Blueprint (older version), and the other is based on susy grid (newer version).
Currently, I have to reinstall the right version for the watch process.
Is it possible to run compile with a specified version? It would be great if it is also possible to run a watch process with a specified version.
Running it as
compass _0.10.5_ compile
will do what you want. (Where you put in the desired version in place of 0.10.5, obviously.)
The tool you're looking for is probally rvm which allows you to have different versions of ruby/gems installed and easily switch between them.
Perhaps there's a simpler way.
If you can use something like Codekit or Livereload, those tools allow you to used embedded sass libraries or define your own.
That you could use the builtin libraries for one project and your custom ones for other projects.
RVM suggested above also works i believe but never tried myself.
I'm wrote an application and I need to execute it on Gentoo,
but when I try run it, I get the following message:
/lib/libc.so.6: version `GLIBC_2.3.4' not found (required by /usr/local/myapp/lib/myapplib.so.1)
the current GLIBC version in this gentoo is 2.3.2.
I can't update this glibc, because I don't have permission, so I need to 'downgrade'
my glibc to the same version (2.3.2) ... how can I do it?
tks,
The "/lib/libc.so.6: version `GLIBC_2.3.4' not found" problem comes from trying to run a binary compiled against a newer glibc on a system with an old version of glibc. Downgrading glibc is strongly discouraged for this reason.
Since you say you wrote the application, it seems to me that the simplest solution is to recompile the application on the system where you plan to run it.
I'm actually wrestling with the same issue, so maybe I have some information that can help.
In short, your binary was compiled to look for libc.so.6. GLIBC_2.3.4 is in libc.so.5. As far as I know, if you downgrade your glibc on your dev machine some of your other programs may not work properly (because they were compiled to look for the current version). Somehow CentOS/RHEL have a compat-glibc package that can live along side of a current glibc without causing this error. If your dev box uses CentOS/RHEL, install that package/recompile and you should be good to go. You may need to use an older compiler for it to look for the older library. If you're not developing on CentOS/RHEL, continue on.
My plan of attack today is to compile glibc from source. This means using a compiler that was released around the same time as the older version of glibc. You may run into some stumbling blocks (such as needing an older version of buildutils, etc.), but my hope is once the libc.so.5 is compiled and installed into /usr/local/lib my application will find that before it finds libc.so.6 in /lib.
So there it is. It's not for the faint of heart, and it's definitely not a quick solution. Today I plan on testing this out, so I can't really say it's the right solution. Please, hivemind.. if I'm flat-out wrong correct me and save this poor soul from this winding torturous road :-)
EDIT: link to glibc sources
At work I'm using Perl 5.8.0 on Windows.
When I first put Perl on, I went to CPAN, downloaded all the sources, made a few changes (in the .MAK file(?) to support threads, or things like that), and did nmake / nmake test / nmake install. Then, bit by bit, I've downloaded individual modules from CPAN and done the nmake dance.
So, I'd like to upgrade to a more recent version, but the new one must not break any existing scripts. Notably, a bunch of "use" modules that I've installed must be installed in the new version.
What's the most reliable (and easiest) way to update my current version, ensuring that everything I've done with the nmake dance will still be there after updating?
As others noted, start by installing the new perl in a separate place. I have several perls installed, each completely separate from all of the others.
To do that, you'll have to configure and compile the sources yourself. When you run configure, you'll get a chance to specify the installer. I gave detailed instructions for this in an "Compiling My Own Perl" in the Spring 2008 issue of The Perl Review. There's also an Item in Effective Perl Programming that shows you how to do it.
Now, go back to your original distribution and run cpan -a to create an autobundle file. This is a Pod document that lists all of the extra stuff you've installed, and CPAN.pm understands how to use that to reinstall everything.
To install things in the new perl, use that perl's path to start CPAN.pm and install the autobundle file you created. CPAN.pm will get the right installation paths from that perl's configuration.
Watch the output to make sure things go well. This process won't install the same versions of the modules, but the latest versions.
As for Strawberry Perl, there's a "portable" version you can install somewhere besides the default location. That way you could have the new perl on removable media. You can test it anywhere you like without disturbing the local installation. I don't think that's quite ready for general use though. The Berrybrew tool might help you manage that.
Good luck, :)
I would seriously consider looking at using Strawberry Perl.
You can install a second version of Perl in a different location. You'll have to re-install any non-core modules into the new version. In general, different versions of Perl are not binary compatible, which could be an issue if you have any program-specific libraries that utilize XS components. Pure Perl modules shouldn't be affected.
If you stay within the 5.8 track, all installed modules that contain XS (binary) extensions will continue to work, as binary compatibility is guaranteed within the same 5.8 series. If you moved to 5.10 then you would have to recompile any modules that contain XS components.
All you need to do is ensure that the new build lists the previous include directories in its #INC array (which is used to look for modules).
By the sounds of it, I think you're on Windows, in which case the current #INC paths can be viewed with
perl -le "print for #INC"
Make sure you target your new Perl version in another directory. It will happily coexist
with the previous version, and this will allow you to choose which Perl installation gets used; it's just a question of getting your PATH order sorted out. As soon as a Perl interpreter is started up, it knows where to look for the rest of its modules.
Strawberry Perl is probably the nicest distribution on Windows these days for rolling your own.
I think the answer to this involves virtualisation of some kind:
Set up an exact copy of your current live machine. Upgrade Perl, using the same directory locations and structures as you're using at the moment.
Go through your scripts testing them on the new image.
Once you're happy, flip the switch.
The thinking behind this is that there's probably all sorts of subtle dependencies and assumptions you haven't thought of. While unlikely, the latest version of a particular module (possibly even a core module, although that's even more unlikely) might have a subtle difference compared to the one you were using. Unless you've exhaustively gone through your entire codebase, there's quite possibly a particular module that's required only under certain circumstances.
You can try and spot this by building a list of all your scripts - a list that you should have anyway, by dint of all your code being under version control (you are using version control, e.g. Subversion, yes?) - and iterating through it, running perl -c on each script. e.g. this script. That sort of automated test is invaluable: you can set it running, go away for a coffee or whatever, and come back to check whether everything worked. The first few times you'll probably find an obscure module that you'd forgotten about, which is fine: the whole point of automating this is so that you don't have to do the drudge-work of checking every single script.
When I did it I installed the newer one into a separate directory. There's a bit of added confusion running two versions, but it definitely helps make sure everything's working first, and provides a quick way of switching back to the old one in a pinch. I also set up Apache to run two separate services, so I could monkey around with the newer Perl in one service without touching the production one on the old Perl.
It's probably a lot wiser, in hindsight, to install on a separate computer, and do your testing there. Record every configuration change you need to make.
I am not sure about building it yourself—I always just used prepackaged binaries for Windows.
I'm not sure I understand exactly what you're asking. Do you have a list of changes you made to the 5.8 makefile? Or is the question how to obtain such a list? Are you also asking how to find out which packages above the base install you've obtained from CPAN? Are you also asking how to test that your custom changes won't break those packages if you get them from CPAN again?
Why don't you use ActivePerl and its "ppm" tool to (re)install modules?