Re: [Plib-users] Library Initialization

[Sam S. <sa...@sp...>]

> > I think it's only on RedHat 7.0 as a getout for Alan Cox's decision to
the
> > development release of gcc.
>
> So they were WELL AWARE of what they were doing - and the kernel guys
complained
> and they STILL WENT AHEAD!  Yikes!  This is much worse than I thought.

Well we're getting wildly offtopic but here's Alan Cox's statement on the
gcc inclusion:

----
From there, the argument ensued at full strength, with Linux kernel
developer and Red Hat employee Alan Cox taking up the cause of Red Hat's
decision to release Red Hat 7 with these packages. Cox's primary argument
was that the inclusion of application like GCC 2.96 is innovative progress
for users of Red Hat 7.

"I want people to be prepared to ship new and innovative things," Cox wrote
in the discussion, "If everyone complains about not shipping precise
reference kernels, then all of a sudden for [kernel] 2.2 I become some
anointed high power for approval for vendors--that is something I don't wish
to be and which would be very, very bad for Linux. Do you really want a
world where you cannot buy a distribution with 2.2 that has Reiserfs because
Alan Cox refused to merge it with the mainstream?"
----

And later on

----
Cox's comments were echoed by Eric Troan, Red Hat's VP of Product
Engineering in an online interview with Linux Today.

"The questions which have arrived over the compiler is actually about the
user-space compiler we ship, not the kernel compiler. The kernel compiler is
essentially the same version we shipped in the last couple of Red Hat
releases," Troan explained. "The user space is based on a snapshot version
of gcc, which we have tested extensively inside of Red Hat. While no
compiler is perfect, we've built tens of millions of lines of code and it
works very well for us."
----

But most worrying is this statement:

----
Troan went on to outline Red Hat's position towards the accusations that Red
Hat is attempting to depart from the Linux standard.

"As for the compatibility issues, we do think binary compatibility between
Linux distributions is very important. We do not ship kernels with extra
APIs unless Linus Torvalds has accepted those new APIs into the development
kernel trees. Likewise, we work hard to maintain full backwards
compatibility," Troan said.

"As the Linux Standard Base (LSB) group gets finalized, Red Hat will be
fully compliant with it's recommendations, ensuring that LSB compatible
applications will run on the widest varieties of Linux-compatible systems
possible," Troan continued, "Fragmenting the Linux binary APIs will not help
anyone.

"Moving Linux forward is important, however. Doing that requires changes
that can make it difficult to move applications from newer systems to older
ones. This is inevitable, and every platform vendor has this type of problem
(applications built for Windows 2000 apps do not work on Windows 98, for
example, and Solaris applications do not run on SunOS). The LSB will provide
a common denominator to allow application compatibility between releases
while still providing a path for new features to be added to Linux
distribution," Troan explained.
----

(He's wrong btw, apps compiled under Windows 2000 run just fine on 98
providing you don't make use of any API's that don't exist on 98).

Sam

> > > > alias gcc kgcc
> > > >
> > > > might do the trick
> > >
> > > ...and g++ ==> kg++ ?
> > >
> > > I don't think an 'alias' will work BTW, the Makefile system probably
uses
> > > bash or something.
> >
> > Yeah, I was thinking it might do that but I don't have to much
experience
> > with the way Unix shells handle their environments.  I supposed you
could
> > add the aliases to.bashrc but to...
>
> The way things are set up is to try to avoid user's own aliases creeping
> into scripts and Makefiles and such.  People like to do thing like:
>
> alias ls ls -al
> alias rm rm -i
> alias test /home/steve/binaries/my_test_program
>
> ...which can play **HAVOC** with system scripts, configure scripts and
> Makefiles!!
>
> The system doesn't prevent you from doing things like that (because
> UNIX likes to give you all the power it can) - but it is mildly
> resistant to non-knowledgeable users tinkering.
>
> > > rename the original gcc/g++ to something else and
> > > symlink to them to kgcc or whatever.
> >
> > ...is probably a better solution.
>
> Yes.
>
> --
> Steve Baker   HomeEmail: <sjb...@ai...>
>               WorkEmail: <sj...@li...>
>               HomePage : http://web2.airmail.net/sjbaker1
>               Projects : http://plib.sourceforge.net
>                          http://tuxaqfh.sourceforge.net
>                          http://tuxkart.sourceforge.net
>                          http://prettypoly.sourceforge.net
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>