Red Hat Topics - detecting RH version in GNUMakefile

Author

detecting RH version in GNUMakefile

deodiaus

2004-11-12, 5:45 pm

How does one find out which version of RH is installed on a particular
machine?

I am trying to detect the version of RH on which future we will be doing a
build.
I can't believe that this is not more standardized, and for the last 30
years everyone has been writting something like this!
I do this by looking at uname -r and associating the kernal with that
version!
Will this work? I see one problem it that if the sys op updated the kernal,
this could potentially break

#-----------GNUMakefile -----------------
UNAMES = $(shell uname -s)
ifeq ($(UNAMES),SunOS)
SSLIPATH = -I../os/Solaris/Solaris32/ssl/include \
-I../os/Solaris/Solaris32/ssl/include/openssl
else
ifeq ($(UNAMES),Linux)
UNAMER = $(shell uname -r)
UNAMER1 = $(join v,$(UNAMER))
UNAMER2=$(findstring v2.4,$(UNAMER1))
ifeq ($(UNAMER2),v2.4)
SSLIPATH = -I../os/Linux/LinuxRH7/ssl/include \
-I../os/Linux/LinuxRH7/ssl/include/openssl
else
UNAMER1 = $(join v,$(UNAMER))
UNAMER2=$(findstring v2.5, $(UNAMER1))
ifeq ($(UNAMER2),v2.5) #rh9
SSLIPATH = -I../os/Linux/LinuxRH9/ssl/include \
-I../os/Linux/LinuxRH9/ssl/include/openssl
else
SSLIPATH = -I../os/Linux/LinuxRHE3/ssl/include \
-I../os/Linux/LinuxRHE3/ssl/include/openssl
endif#rh9
endif#rh7
else
SSLIPATH = -I../os/WINDOWS/WIN32/ssl/include \
-I../os/WINDOWS/WIN32/ssl/include/openssl
endif#Linux
endif#SunOS
# more code to follow
#---------------------------eof-------------------------

Rich Teer

2004-11-12, 5:45 pm

On Fri, 12 Nov 2004, deodiaus wrote:

> How does one find out which version of RH is installed on a particular
> machine?

I have no idea. Nor do I know what this has to do with Solaris.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Ivan Marsh

2004-11-12, 5:45 pm

On Fri, 12 Nov 2004 19:41:40 +0000, Rich Teer wrote:

> On Fri, 12 Nov 2004, deodiaus wrote:
>
>
> I have no idea. Nor do I know what this has to do with Solaris.

By reading /etc/redhat-release

I don't know what it has to do with Solaris either.

--
"No oppression is so heavy or lasting as that which is inflicted by
the perversion and exorbitance of legal authority."
i.m.

Dan Espen

2004-11-12, 5:45 pm

"Ivan Marsh" <annoyed@you.now> writes:

> On Fri, 12 Nov 2004 19:41:40 +0000, Rich Teer wrote:
>
>
> By reading /etc/redhat-release
>
> I don't know what it has to do with Solaris either.

Not much, but Solaris was one of the OSs the makefile was detecting.

To the OP, the way you did that is pretty much
the I do it.
The only way to simplify it would be
to set
up a variable before invoking make.

Moe Trin

2004-11-13, 8:45 pm

In article <52ddc198.0411120859.3d257017@posting.google.com>, deodiaus wrote:

>How does one find out which version of RH is installed on a particular
>machine?

With nearly all current versions of Linux, you simply cat a file in
/etc/ that is named after the distribution.

Annvix: /etc/annvix-release
Arklinux: /etc/arklinux-release
BlackCat /etc/blackcat-release
Cobalt /etc/cobalt-release
Conectiva /etc/conectiva-release
Debian: /etc/debian_version
Gentoo: /etc/gentoo-release
Fedora /etc/fedora-release
Immunix: /etc/immunix-release
Linux-PPC /etc/linuxppc-release
Mandrake: /etc/mandrake-release
MkLinux /etc/mklinux-release
Red Hat: /etc/redhat-release
Slackware: /etc/slackware-version
SME Server (Formerly E-Smith) /etc/e-smith-release
SuSE: /etc/SuSE-release
Tiny Sofa /etc/tinysofa-release
TurboLinux /etc/turbolinux-release
UltraPenguin /etc/ultrapenguin-release
VA-Linux /etc/va-release
YellowDog /etc/yellowdog-release

So it's pretty obvious you want to 'cat /etc/*release /etc/*version'

>I can't believe that this is not more standardized, and for the last 30
>years everyone has been writting something like this!

I can't believe you haven't discovered this by a simple search on google.

[pennyweight ~]$ cat /etc/redhat-release
Red Hat Linux release 3.0.3 (picasso)
[pennyweight ~]$

>I see one problem it that if the sys op updated the kernal, this could
>potentially break

Seeing as how FOR EXAMPLE Red Hat 9 had no less than NINE kernel updates
over it's supported life of thirteen months, nevermind someone compiling
their own kernel for one reason or another, yeah - that's probably a
bad idea.

Old guy

ishikawa

2004-11-14, 7:45 am

> With nearly all current versions of Linux, you simply cat a file in
> /etc/ that is named after the distribution.
>
> Annvix: /etc/annvix-release
> Arklinux: /etc/arklinux-release
> BlackCat /etc/blackcat-release
> Cobalt /etc/cobalt-release
> Conectiva /etc/conectiva-release
> Debian: /etc/debian_version

I am using debian on my home PC and found the above file.
ishikawa@duron$ cat /etc/debian_version
3.1
ishikawa@duron$ uname -a
Linux duron 2.6.9-test-tmscsim #13 Sun Nov 7 19:40:30 JST 2004 i686
GNU/Linux
ishikawa@duron$

> So it's pretty obvious you want to 'cat /etc/*release /etc/*version'
>
>
>
>
> I can't believe you haven't discovered this by a simple search on google.
>

I have been using Debian for a few years, and have never heard of this
file. More things to learn, I guess. Too bad Debian uses *version
variant unlike the others.

I use my home PC for software development as well as for e-mails, web
surfing, etc..

For software development, I have come across portability issues.
I have dealt with Solaris for Sparc/X86, (Dec's Ultrix, HP's HPUX
in the old days), and linux (mostly debian varieties and RedHat), and
other non-POSIX OSes.
Most of the time, I count on the output of "uname -a" to
differentiate the versions of linux (debian, redhat), and Solaris
for which I have ported my programs. (For non-Posix systems such as
embedded systems that I need to cross-compile, I need to create
different Makefiles because supporing all these in one big Makefile
tends to be messy.)

>
>
>
> Seeing as how FOR EXAMPLE Red Hat 9 had no less than NINE kernel updates
> over it's supported life of thirteen months, nevermind someone compiling
> their own kernel for one reason or another, yeah - that's probably a
> bad idea.
>

For Debian which I use on my home PC,
which is known for a very slow release / update to catch
up with latest kernel features (not that the slowness
is bad in itself, but there
are some users whose hardware require the latest drivers that only work
in very new kernel updates), some users like myself have downloaded the
linux mainline kernel and compile our own version. I have no idea what
version of the linux kernel is shipped with Debian 3.1.
But I upgraded kernels on my own for the last few years anyway.

In this sense, I think using Solaris X86 is a winner even on an x86 PC
when it comes to commercial distribution of application software.
At least Sun still continues to offer patches for Solaris 8 (I think)
and there are customers whose application software packages have been
tested on Solaris 8 can't easily upgrade to newer OS easily. For a
distributor like the original poster, we can ascertain that even the
users of old Solaris 8 use the expected
versions of various libraries you depend
if the users haven't installed the patches, you can direct them to
sunsolve and obtain the current patches. Support of an OS a couple of
major revisions ago is a serious issue for ISVs.

That said, somehow Sun's Star Offce (called StarSuite in Japan due
to trademark problem) installed fine on my PC and works like a charm
with subtle MS compatibility bugs included :-)
I installed it under linux kernel 2.4.x and am using it under 2.6.y now.
I have not investigated it, but I suspect that Sun's installer must have
checked library availability and other things when the program was
installed, and if some are missing, probably installed them in a private
directory.

The best bet for the original poster is to
check the value of uname -a and depend on it to guide
make's operation until
someone with a somewhat unusual flavor of
linux/POSIX/whatever comes along
and says Makefile is broken, then it is time to sit down and
fix things. That someone probably is willing to help the original
poster to modify Makefile because it is highly likely that he/she
needs to tackle porting issues often.
(If not, then just tell him/her to use a well known brand of OS.)

Moe Trin

2004-11-15, 8:45 pm

In article <1100441770.405021@duron>, ishikawa wrote:

>I have been using Debian for a few years, and have never heard of this
>file. More things to learn, I guess. Too bad Debian uses *version
>variant unlike the others.

I know that Red Hat had this file in 1995, and that distributions that
looked at RH (or used rpm as a package manager) seem to have joined the
bandwagon. Back in 1996 or so, someone created a script that "inventoried"
a Linux system, and this was one of the keys they were looking for. I've
long since lost that script. Debian isn't the only one using *version,
as Slackware is using it also.

>Most of the time, I count on the output of "uname -a" to
>differentiate the versions of linux (debian, redhat), and Solaris
>for which I have ported my programs.

While that certainly differentiates between Linux, Solaris, or *BSD, it's
pretty unreliable for identifying _which_ Linux distribution. While many
distributions are sticking some clues into their kernel names or perhaps
the name of the system that compiled the kernel, the person who decides to
get the latest kernel from kernel.org isn't likely to do so.

Oh, and be cautious about trusting the file _name_ as the identifier.
Mandrake has /etc/redhat-release as a soft link to /etc/mandrake-release.
A good idea is to actually read the _contents_ of the file.

>In this sense, I think using Solaris X86 is a winner even on an x86 PC
>when it comes to commercial distribution of application software.

The people at Red Hat (among others) might disagree with you there. ;-)

>At least Sun still continues to offer patches for Solaris 8 (I think)
>and there are customers whose application software packages have been
>tested on Solaris 8 can't easily upgrade to newer OS easily.

You'd expect that of a commercial distribution. In general, the popular
Linux distributions seem to be on a six month release cycle (new release
twice a year), and the distributions tend to have a supported life of 18
36 months. I've had very limited experience with Solaris X86, but feel
is has much less in the line of supported hardware.

>I installed it under linux kernel 2.4.x and am using it under 2.6.y now.
>I have not investigated it, but I suspect that Sun's installer must have
>checked library availability and other things when the program was
>installed, and if some are missing, probably installed them in a private
>directory.

How does one say a specific library or other dependency is there? Do you
look for it? Where? Despite the Filesystem Hierarchy Standard
http://www.pathname.com/fhs/, not every distribution puts things in
exactly the same location - don't forget, we're talking about 100+
distributors. Try to load a test application that uses the normal system
path to linkers/loaders/libraries/etc., and see what version it might be
finding where? Installing in a private space might work, provided you then
lock your application to NEVER look elsewhere, in case the local admin
installs a different version of your missing dependency at a later date
for a different reason.

>The best bet for the original poster is to check the value of uname -a
>and depend on it to guide make's operation until

I'd suggest using 'uname -a' to find which O/S you have. If it indicates
it is Linux, then look at /etc/*release and /etc/*version to identify
which distribution and release. Not foolproof, because we have some
_very_ inventive fools.

Old guy