My program can't work on redhat enterprise AS 4 - Linux

This is a discussion on My program can't work on redhat enterprise AS 4 - Linux ; hello all: I have a puzzle now. my program compiled on Fedora 7, version of kenel is 2.6.20-2925.9.fc7xen, but when I run it on our sever, wich is runing Redhat enterprise as4 whose kernel version is 2.6.9-42, it doesn't work, ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: My program can't work on redhat enterprise AS 4

  1. My program can't work on redhat enterprise AS 4

    hello all:
    I have a puzzle now. my program compiled on Fedora 7, version of
    kenel is 2.6.20-2925.9.fc7xen, but when I run it on our sever, wich
    is runing Redhat enterprise as4 whose kernel version is 2.6.9-42, it
    doesn't work, and floating point exception happened, however,
    strangely the program work normally in my machine(fedora7). what's
    wrong with it? something about kernel, gcc? My program is a network
    server program.
    thanks in advance, I'm confused with it for two days, please help me.


  2. Re: My program can't work on redhat enterprise AS 4

    On 5 Jul, 09:02, Kevin wrote:
    > I have a puzzle now. my program compiled on Fedora 7, version of
    > kenel is 2.6.20-2925.9.fc7xen, but when I run it on our sever, wich
    > is runing Redhat enterprise as4 whose kernel version is 2.6.9-42,


    Are you running on RHAS 4 an executable built on Fedora? If so, why?
    Your problem will be greatly simplified if you build the executable
    on the same machine you run it on.


  3. Re: My program can't work on redhat enterprise AS 4

    In article <1183622578.232240.187650@e9g2000prf.googlegroups.c om>,
    Kevin wrote:

    >I have a puzzle now. my program compiled on Fedora 7, version of
    >kenel is 2.6.20-2925.9.fc7xen, but when I run it on our sever, wich
    >is runing Redhat enterprise as4 whose kernel version is 2.6.9-42, it
    >doesn't work, and floating point exception happened, however,


    "Doctor, it hurts when I does this..."

    So compile it on the Red Hat system.

    --
    http://dating.blameitonlove.com

  4. Re: My program can't work on redhat enterprise AS 4

    William Pursell writes:
    > On 5 Jul, 09:02, Kevin wrote:
    >> I have a puzzle now. my program compiled on Fedora 7, version of
    >> kenel is 2.6.20-2925.9.fc7xen, but when I run it on our sever, wich
    >> is runing Redhat enterprise as4 whose kernel version is 2.6.9-42,

    >
    > Are you running on RHAS 4 an executable built on Fedora? If so, why?
    > Your problem will be greatly simplified if you build the executable
    > on the same machine you run it on.


    Is 'our Linux products are not compatible with each other' a new
    feature of DeadRat-Linux?


  5. Re: My program can't work on redhat enterprise AS 4

    Kevin wrote:
    > hello all:
    > I have a puzzle now. my program compiled on Fedora 7, version of
    > kenel is 2.6.20-2925.9.fc7xen, but when I run it on our sever, wich
    > is runing Redhat enterprise as4 whose kernel version is 2.6.9-42, it
    > doesn't work, and floating point exception happened, however,
    > strangely the program work normally in my machine(fedora7). what's
    > wrong with it? something about kernel, gcc? My program is a network
    > server program.
    > thanks in advance, I'm confused with it for two days, please help me.
    >


    Build low, test high. Don't build on a system that is fundamentally
    newer than the one you want to test on.

  6. Re: My program can't work on redhat enterprise AS 4

    On Jul 6, 1:16 am, Rainer Weikusat wrote:

    > Is 'our Linux products are not compatible with each other' a new
    > feature of DeadRat-Linux?


    This type of compatibility is explicitly not provided. Providing it
    would mean that newer systems could never take advantage of
    fundamentally new features. It would even mean that bugs could not be
    fixed so long as some software relied on those bugs. (As some software
    relied on 'getpid' returning a different value for each thread in
    LinuxThreads.)

    So yes, the absence of this type of brain damaged compatibility *is* a
    feature.

    DS


  7. Re: My program can't work on redhat enterprise AS 4

    David Schwartz writes:
    > On Jul 6, 1:16 am, Rainer Weikusat wrote:
    >> Is 'our Linux products are not compatible with each other' a new
    >> feature of DeadRat-Linux?

    >
    > This type of compatibility is explicitly not provided.


    [...]

    > So yes, the absence of this type of brain damaged compatibility *is* a
    > feature.


    As long as a particular program does not in itself (which means 'in
    application code') use anything specific to the newer system, it
    should run on the older, too, and it is not 'a feature' if it
    doesn't.


  8. Re: My program can't work on redhat enterprise AS 4

    Rainer Weikusat wrote:
    > David Schwartz writes:
    >> On Jul 6, 1:16 am, Rainer Weikusat wrote:
    >>> Is 'our Linux products are not compatible with each other' a new
    >>> feature of DeadRat-Linux?

    >> This type of compatibility is explicitly not provided.

    >
    > [...]
    >
    >> So yes, the absence of this type of brain damaged compatibility *is* a
    >> feature.

    >
    > As long as a particular program does not in itself (which means 'in
    > application code') use anything specific to the newer system, it
    > should run on the older, too, and it is not 'a feature' if it
    > doesn't.


    Correct, but the app most likely uses the libraries
    of the new system. So it likely won't work on an older one.
    You may be able to cobble together a build environment with old
    libraries on the new system.

    Best advice if you want it to run on an old system build it on an
    old system. Then it will also run on a new system

  9. Re: My program can't work on redhat enterprise AS 4

    On Jul 16, 8:58 am, Rainer Weikusat wrote:

    > As long as a particular program does not in itself (which means 'in
    > application code') use anything specific to the newer system, it
    > should run on the older, too, and it is not 'a feature' if it
    > doesn't.


    This means you can't fix bugs because older code may rely on the bugs.
    That's applicable to this exact case because older systems used
    LinuxThreads, which returned a different value for 'getpid' in each
    thread. Newer systems don't do this.

    So you are essentially arguing that a bug of this type must be
    maintained (or at least emulated) forever.

    Even Windows, which has the most legacy support of any OS I know of,
    dropped support for 16-bit executables in the 64-bit versions. At some
    point, you have to break compatibility, and unfortunately this guy got
    stuck right at a major changeover (LinuxThreads to NPTL).

    I agree that such compatibility should not gratuitously be broken, but
    proper POSIX threads supports is more important.

    DS


  10. Re: My program can't work on redhat enterprise AS 4

    David Schwartz writes:
    > On Jul 16, 8:58 am, Rainer Weikusat wrote:
    >
    >> As long as a particular program does not in itself (which means 'in
    >> application code') use anything specific to the newer system, it
    >> should run on the older, too, and it is not 'a feature' if it
    >> doesn't.

    >
    > This means you can't fix bugs because older code may rely on the
    > bugs.


    It doesn't contradict such a statement because it was a statement
    about the opposite case.


  11. Re: My program can't work on redhat enterprise AS 4

    On Jul 16, 3:32 pm, Rainer Weikusat wrote:

    > David Schwartz writes:
    > > On Jul 16, 8:58 am, Rainer Weikusat wrote:


    > >> As long as a particular program does not in itself (which means 'in
    > >> application code') use anything specific to the newer system, it
    > >> should run on the older, too, and it is not 'a feature' if it
    > >> doesn't.


    > > This means you can't fix bugs because older code may rely on the
    > > bugs.


    > It doesn't contradict such a statement because it was a statement
    > about the opposite case.


    I don't follow. If the newer system doesn't have bugs that the older
    system does, code written on the newer system won't work on the older
    system because of the bugs. The only solutions are:

    1) Don't fix the bugs.

    2) Break compatibility and fix the bugs, knowing that code that relies
    on the bugs won't work on older systems.

    This is exactly what happened here. The old system had a bug. That bug
    was fixed. Current code relies on the fix and old code relied on the
    bug.

    DS


  12. Re: My program can't work on redhat enterprise AS 4

    In article <1184646075.608050.83920@i13g2000prf.googlegroups.c om>,
    David Schwartz wrote:

    >1) Don't fix the bugs.


    Isn't that the M$ way?

    --
    http://www.spinics.net/lists/

  13. Re: My program can't work on redhat enterprise AS 4

    David Schwartz writes:
    > On Jul 16, 3:32 pm, Rainer Weikusat wrote:
    >> David Schwartz writes:
    >> > On Jul 16, 8:58 am, Rainer Weikusat wrote:

    >
    >> >> As long as a particular program does not in itself (which means 'in
    >> >> application code') use anything specific to the newer system, it
    >> >> should run on the older, too, and it is not 'a feature' if it
    >> >> doesn't.

    >
    >> > This means you can't fix bugs because older code may rely on the
    >> > bugs.

    >
    >> It doesn't contradict such a statement because it was a statement
    >> about the opposite case.

    >
    > I don't follow.


    You are arguing about programs which depend on pecularities of either
    the older or the newer system. I am writing about programs depending
    on neither of both which break because of changes unrelated to them.
    And that is something which should be avoided if possible.

  14. Re: My program can't work on redhat enterprise AS 4

    ellis@no.spam () writes:
    > In article <1184646075.608050.83920@i13g2000prf.googlegroups.c om>,
    > David Schwartz wrote:
    >
    >>1) Don't fix the bugs.

    >
    > Isn't that the M$ way?


    It is reportedly the HP-UX way. The Microsoft way would be to
    introduce new bugs with code trying to work around old bugs.

  15. Re: My program can't work on redhat enterprise AS 4

    On Jul 17, 12:08 am, el...@no.spam () wrote:
    > In article <1184646075.608050.83...@i13g2000prf.googlegroups.c om>,
    > David Schwartz wrote:


    > >1) Don't fix the bugs.


    > Isn't that the M$ way?


    Yes and no. It's true that Microsoft will refrain from fixing bugs,
    and sometimes even create them, for the sake of backwards
    compatibility. This is not always such a bad thing because backwards
    compatibility does have value. Everyone has to strike a balance
    between fixes and improvements on one hand and proven working code on
    the other.

    Fortunately, we can make better trade-offs in the open source world.
    We presume that recompiling code is not all that big a deal, so we can
    fix bugs that break compatibility if all it takes is a recompile.

    However, if you want this, you can't complain too quickly about having
    to recompile. The alternative is to keep the bugs.

    DS


  16. Re: My program can't work on redhat enterprise AS 4

    On Jul 17, 2:14 am, Rainer Weikusat wrote:

    > You are arguing about programs which depend on pecularities of either
    > the older or the newer system. I am writing about programs depending
    > on neither of both which break because of changes unrelated to them.
    > And that is something which should be avoided if possible.


    True. In this case, it is a possible dependency on a peculiarity. One
    problem is that it's not always easy to tell which programs depend on
    a major peculiarity, and you have to make a decision between breaking
    compatibility for all programs that might depend on it or risking
    having a program do the wrong thing.

    In any event, having code developed and compiled on a newer machine
    work on an older machine requires, at a minimum, bloating the new code
    with any code that might not be present in a system library on an
    earlier machine. The problem in his case is lack of exactly that bloat
    and the risk that the program depends on LinuxThreads peculiarities.

    DS


  17. Re: My program can't work on redhat enterprise AS 4

    On Jul 17, 2:14 am, Rainer Weikusat wrote:

    > You are arguing about programs which depend on pecularities of either
    > the older or the newer system. I am writing about programs depending
    > on neither of both which break because of changes unrelated to them.
    > And that is something which should be avoided if possible.


    I wrote a response to this that got lost in the ether. Here's the gist
    of it:

    Yes, I agree with you. If there is no overwhelming cost to maintaining
    compatibility, by all means do it. Gratuitously breaking compatibility
    is bad.

    But staying bug-for-bug compatible for the sake of compatibility or
    bloating programs with code that's already in the new versions of
    shared libraries can be costs that exceed the compatibility benefit.
    Microsoft Windows is a good example of a platform that pays huge costs
    for the sake of binary compatibility. In the UNIX world, a more common
    assumption is that recompiling is no big deal, especially to make code
    work on *older* platforms.

    In any event, the type of compatibility at issue here is generally
    provided by nobody and basically never guaranteed. Newer machines and
    operating systems have newer features, and the code can only work on
    older machines and operating systems if you do not use them.

    In this case, the change was a complete re-design of the way multi-
    threading was handled. The new code fixes major bugs in the old code
    but requires kernel support to do so. His kernel did not have that
    support, so running on the older kernel would bring the bugs back. The
    bugs are fundamental enough that it's not reasonable (or desirable) to
    let the code run with them.

    DS


  18. Re: My program can't work on redhat enterprise AS 4

    In article <1184743922.353991.111210@d30g2000prg.googlegroups. com>,
    David Schwartz wrote:

    >> Isn't that the M$ way?


    >Yes and no. It's true that Microsoft will refrain from fixing bugs,
    >and sometimes even create them, for the sake of backwards
    >compatibility. This is not always such a bad thing because backwards
    >compatibility does have value. Everyone has to strike a balance
    >between fixes and improvements on one hand and proven working code on
    >the other.


    Wow, you took my comment *way* too seriously.


+ Reply to Thread