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.

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

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?

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.

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

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.

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

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

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.

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

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/

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.

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.

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

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

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

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.