> -----Original Message----- > From: redhat-list-admin@xxxxxxxxxx [mailto:redhat-list-admin@xxxxxxxxxx] > On Behalf Of Gordon Messmer > Sent: Thursday, October 16, 2003 11:29 AM > To: redhat-list@xxxxxxxxxx > Subject: Re: C++ lib compatibility between Red Hat 9 and 7.3 > > Otto Haliburton wrote: > > > > Look at it this way. You should be able to move a c++ (not g++) > compiler to > > any version of RH and it works!!! LIB's and all period, no explanation > > needed. > > I agree. You should be able to... but you can't. Maybe someday you > will be able to. If the current promise of a stable ABI is kept, then > someday may be now. > > > Fact, it doesn't. The question is why. The explanation is that it > > is native to c++ and only c++ was stated. I was pointing out that > actually > > it is a problem of the community that I believe is related to the > resources > > available to the developers. > > That's where I think you're pointing fingers without understanding the > situation. As it's been said, this is not a problem that's unique to > the Free Software community. Generally, you can exect that different > versions of a compiler will produce compatible C binaries. You can also > often expect that different vendors compilers will produce compatible C > binaries. There is a binary compatibility standard for C. There is no > such standard for C++. You will not be able to link objects from one > vendor's compilers against another's. > > This has been true of Intel's C++ compiler. It's been true of Sun's C++ > compiler for Sparc. Are you going to tell us that it's because those > developers don't understand the CPUs well enough? Or that they don't > understand how to build binaries that run on those CPUs? Or that they > don't have the time/money/resources to do it right? Get real. > You are completely of base as to what the point is. It is not the developers that have the problem as you are talking about. They don't have the resources to thoroughly checkout the compilers. Actually, it is not the compiler that is the problem. Remember that when you compile a program, it is the responsibility of the linker to resolve the symbols and the addresses no matter what the objects look like. So if a library contains a routine with the same name as a routine in another library then it should resolve to the routine it has. So I don't know that you know what you are talking about. My point is that since developers are restricted in resources that don't have the ability to test the compilers properly so therefore until it is used widely they can't fix it so that is a reason for a large number of compatibility problems. So you need to read better. > > The individual in question made a statement > > that effectively, it should be accepted without complaints and I said > and I > > still say that is dumb. > > I think the general idea is that no amount of bitching is going to > change history, so don't. Very intellegent, talented, experienced > people work on the compiler, and history shows that they *still* weren't > able to get a good ABI on the first try. From your perspective, which > as far as we know does *not* include extensive experience developing a > compiler or an ABI, it seems like it should be a simple thing. Good for > you. When you've *done* it, then you can preach about how everyone in > the world has done it wrong so far. > Again you miss the point, it is bitching and complaining that brings the problem to the front so it can be fixed. > > This needs to be fixed to where anyone can select a > > new compiler and not worry that it will break everything else and you > need > > resources to test it against all previous versions. If you don't then > no > > one will accept open community software period. > > OK. Which compiler will they use? The one that works out of the box and if necessary will pay for the one that works. > > I think by your comments you completely missed the point. -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
