Re: detecting RH version in GNUMakefile

From: ishikawa (
Date: 11/14/04

  • Next message: Beardy: "Re: Solaris 10 b69 autofs problem"
    Date: Sun, 14 Nov 2004 23:16:10 +0900

    > 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
    ishikawa@duron$ uname -a
    Linux duron 2.6.9-test-tmscsim #13 Sun Nov 7 19:40:30 JST 2004 i686

    > 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.

    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.)

    >>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.

    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

    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.)

  • Next message: Beardy: "Re: Solaris 10 b69 autofs problem"