We have an old OLD binary which was built on OLD Solaris OS (pre Solaris 10 version).
I need to rebuild some of its code in same Old Solaris OS.. No one know in which version it was built and no machine details available..
The binary is running on Solaris 10. But for some backward compatibility purpose (believe me.. ) they still wanted it to built on Old Solaris.
is there a way to find in which OS version that binary was build..? (last stupid belief).
Depending on how the binary was built, the command:
mcs -p binary
might give you a good hint.
Otherwise, as Andrew suggested (with optional filtering added):
strings -a binary | egrep -i "solaris|sunos|version|5\."
Related
Trying to install swift on my Ubuntu 14.04.3 server. Followed the guide on Swift.org.
download the install package
fetched the gpg keys
verified the .sig file
extracted the file and added the usr/bin subdir to my PATH
However when I try running swift I get "No such file or directory"
Swift seems to be found:
icanzilb#underplot:~/public$ which swift
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift
Path is correct:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ echo $PATH
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin:...
But can't run it:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ swift
-bash: /home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift: No such file or directory
=====
Update 1: I tried the development and stable builds of Swift from swift.org and the .sig checks out but still getting the same error.
Both the swift executable and my Ubuntu are 64 bit.
It really looks like this is a problem of an architecture mismatch, as indicated by one of the commenters, or a corrupted download. The swift executable is in the path and is picked up by which. Judging from the name of the directory where it is located, it is indeed for Ubuntu 14.04. I would try the following:
file `which swift`
This should tell you it is an ELF 64-bit executable, dynamically linked, etc. If that is not the case, you have a corrupted binary somehow.
Then do
uname -a
which should identify your system as Ubuntu 14, x86_64 among other things. If that is the case, you probably have a corrupted binary. Unpack the downloaded package again and retry. If your system is not x86_64, then you are on a wrong architecture.
Update 2/4/2016:
Based on the additional info you provided about the binary and the architecture, I tend to believe this is a platform mismatch. The output of uname doesn't show it is an Ubuntu box. Besides, the Linux kernel is 4.4.0, and the binary is for 2.6.24. I can successfully run the same binary on an Ubuntu 14.04 installation with a 3.19.0 kernel. The kernel version difference is not necessarily a problem in itself, but an indicator that the platform may not be a standard Ubuntu 14.04 install.
As another check, could you please do cat /etc/os-release and cat /etc/lsb-release? Those files should indicate if the platform is indeed Ubuntu. If it is, then I'm wondering how you ended up with this late kernel version. It is possible some other components of the OS are also too recent and incompatible with the Swift binary. This may be some strange custom Linode image... If you have a machine you can use, virtual or physical, try downloading and installing a standard Ubuntu 14.04.
They say here that ICU is used on many platforms. But I can't find what version comes with OS X and Windows. In Linux I suppose a package-manager would tell me.
UPDATE: Changed CLDR to ICU
I don't know whether platforms come bundled with ICU. For sure, Windows does not. Unix-based platforms might. For one, apparently OS X comes bundled with some version of it.
If the platform delivers a full bundle of ICU you can test the version of ICU using the command:
$ uconv -V
Which will print the version. The latest version is 54.1, it looks like this:
uconv v2.1 ICU 54.1
In addition, if your platform has Qt installed, it is possible it has been compiled with ICU support, but this is not a necessity.
If you want to use ICU, you're probably better off shipping it with your product as opposed to rely on what is on someone's system. ICU has a fairly regular update cycle, chances are that pre-installed ICU libraries are out of date.
Completing #Abel's answer, on macOS the complete command to extract the ICU version is:
$(brew --prefix)/opt/icu4c/bin/uconv --version | sed -ne 's/uconv v.* ICU \([0-9][0-9.]*\)/\1/p'
This produces e.g. 72.1 as of today (2022-01-21).
On Ubuntu, uconv is in the PATH if installed, so this is simply:
uconv --version | sed -ne 's/uconv v.* ICU \([0-9][0-9.]*\)/\1/p'
I have CentOS 6.3 installed.
cat /etc/redhat-release
CentOS release 6.3 (Final)
uname -mrs
Linux 2.6.32-279.el6.x86_64 x86_64
I am following the steps outlined in the following links to fetch and build the kernel (to enable certain features):
http://wiki.centos.org/HowTos/I_need_the_Kernel_Source
http://wiki.centos.org/HowTos/Custom_Kernel
In the CentOS 6.3 vault (http://vault.centos.org/6.3/updates/Source/SPackages/), following kernel source rpms are listed:
kernel-2.6.32-279.1.1.el6.src.rpm
kernel-2.6.32-279.2.1.el6.src.rpm
kernel-2.6.32-279.5.1.el6.src.rpm
kernel-2.6.32-279.5.2.el6.src.rpm
kernel-2.6.32-279.9.1.el6.src.rpm
kernel-2.6.32-279.11.1.el6.src.rpm
kernel-2.6.32-279.14.1.el6.src.rpm
kernel-2.6.32-279.19.1.el6.src.rpm
kernel-2.6.32-279.22.1.el6.src.rpm
I am trying to find out, which of the above source rpm corresponds to kernel version 2.6.32-279.el6 (output of "uname -r" which does not contain the additional 2 digits of the version number in the list above). Any help would be very appreciated.
Thank you,
Ahmed.
After much wrecking my head and tons of googling (which did not shed any light), I finally figured out the answer to my question. I will state my answer using CentOS 6.3 as a example, same logic applies to CentOS 6.4. If one has a fresh install of CentOS 6.3, look for the kernel source file at the following site:
http://vault.centos.org/6.3/os/Source/SPackages/
The above site contains only one kernel source rpm (for kernel with the version number that does not contain the two additional digits in the version number). Not confusion there.
However, if one has applied a patch to the stock 6.3 release, then depending on the patch level, the kernel version is extended (with the two digits) for which the corresponding kernel source is available at the following site:
http://vault.centos.org/6.3/updates/Source/SPackages/
--Ahmed.
I have a Perl module that handles localization tasks using the GNU gettext utilities xgettext, msgfmt, msginit, and msgmerge. I got some test failures from a SunOS system which, when I looked into it, seemed to be ancient. For now I am skipping tests when msgfmt and xgettext choke on a simple --version option. But I think it would be better to refuse to install unless a relatively modern version of the GNU Gettext utilities are installed.
So, what's the best way to do that? I'd like to just figure out what's installed and if it supports the options I need, and refuse to install the module if those dependencies are not met. Should I just run gettext --version and refuse to install if it exits with a non-0 value? Or might there be a more canonical solution?
Since "gettext --version" should always return a value on any "contemporary" version (for example, I just tried it on a circa 1997 Redhat ... and it worked!), that should be sufficient.
IMHO...
I am trying to install ruby version manager on a g4 ibook running 10.4 but I receive two error messages right off the bat when I try to run the first command:
$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
bash: line 6: set: errtrace: invalid option name
bash: line 13: conditional binary operator expected
I am new to ruby, rails, and fairly inexperienced with the command line too. I've done a bit of searching and have seen other people having problems installing a specific version of ruby on a powerpc using rvm, but no other examples of someone having a problem installing rvm first of all.
Does this seem like a powerpc issue? Or is there something simple with the command line that I am missing here?
I have also searched on these specific error messages but haven't found any solutions yet. Oh and I should also add that I have xcode installed and I also installed macports because I thought that might help...but it hasn't.
The most probable cause of the error you're getting is your bash version is far too old to be used with any relatively new RVM version. Also, the likelihood of you being able to easily compile rubies on a G4 now is very low. You'll likely end up needing to compile many tools and libraries from source which you'll have to do from the command-line. Finding the right combination of library versions that both support your arch and are still available for download might not be as easy as it sounds. Much of the ruby compilation on OS X depends on libraries that come with Xcode. So, you might hit a wall there too with rubies now requiring newer libraries that can be provided with a version of Xcode that can be installed on your system.
You can try upgrading your bash version and/or use a much older version of RVM, although, I don't remember RVM ever working on 10.4. Or, you can try to compile everything from source, including Ruby. You'll might be able to get Ruby 1.8.6, maybe 1.8.7 working but anything higher is very unlikely.
Good luck =/