FC4 good new tech, bad legacy support
rich at csst.net
Wed Jun 29 20:23:42 UTC 2005
Alas! An individual who actually addressed many of the issues in my
email instead of told me to shut up because I shattered his fanboy view
of the world. Thank you Michael.
Michael Schwendt wrote:
>On Wed, 29 Jun 2005 01:52:01 -0700, Richard Kelsch wrote:
>>Good luck on getting many non-rpmed Perl CPAN modules to work, even
>>though they worked fine in FC3. Not everyone is a C programming master
>>with a PHD. Trying to figure out why someone in their right minds would
>>make a compiler not compile code it's previous versions compiled quite
>>happily is just beyond all logic in my opinion;
>It isn't. Often programmers abuse weaknesses in the strictness of how a
>compiler implements a programming language. Sometimes they do it
>unknowingly, because an older compiler version seems to accept source code
>which it should not accept according to programming language standards.
>When the compiler engineers make the compiler better in terms of
>compliance with the programming language standards, weak source code
>likely breaks. Sometimes in obvious ways, sometimes is less obvious ways.
I am in full agreement with that point of view. Consider this, however,
rather than punish people by removing the capability in the compiler,
why not make it a command line "feature" that can be turned on? This is
enough of a nudge for stray programmers to fix their errant code, but
not as severe as to completely break a whole array of software just
because a group of compiler writers got all indignant over "improper"
coding practices and choose to punish instead of teach. Also, and I am
being serious, not everyone has a PHD in software development and has
probably learned on their own how to program. This, to me, describes
the open-source majority, in my opinion. Frankly, enthusiasts make up
the majority of Linux users. I have been tinkering with computers since
1982 and I have programmed in a variety of languages. Frankly, the only
reason I never went to C was simply for this specific reason. Different
compilers had their own "rules" and they ended up changing as time went
on. I just wanted to write a program and have it work without spending
hours trying to satisfy a specific compiler's quirks.
An open source OS is going to have millions writing software for it. It
needs to be a little more flexible if it is to be a useful platform.
Anal retentiveness is for Windows and counterproductive for a community OS.
>>especially since no
>>English readable error is generated, except something cryptic that only
>>a hippie-haired college professor would decipher at a glance (and
>>probably with a condescending tone too).
>These errors are for programmers. As a non-programmer, it would be very
>difficult for a compiler to explain to you what problem was found in
>the source code.
I am a programmer, just not a C programmer. I'd like to be able to use
the OS as a user as well. Limiting the usefulness of the OS to C
programmers is not too bright in my opinion. Besides, I can't even use
my language of choice without being a C expert as well, at least in
FC4. This is why the Perl programmers design the CPAN interface. When
CPAN breaks, "it" has hit the fan.
>>Good luck downloading anything from sourceforge hoping it will compile.
>One thing packagers ought to do--and with some distributions they don't
>seem to do it unfortunately--is shipping compilation fixes to the software
>developers, so their next release includes such fixes if the developers
>didn't ran into the problems themselves before.
>The reason why you may find programs in Core or Extras, which build and
>work, but which fail to build when you download them from their
>developer's website, is that packagers patched them to make them build.
>Many upstream projects don't use GCC 4.0.0 yet, neither the pristine
>one nor Red Hat's improved and patched version.
One can't "RTFM" unless there's something to read. Perhaps better
documentation written for the casual user/programmer ought to have been
written on how to overcome these errors.
What was most frustrating to me was the Perl "Audio::Mad" module. I had
"libmad" from the freshrpms tree installed, like a good boy; but the
Perl package just refused to compile. It would complain about "lvalues"
or something. So, I edited the Makefile and replaced all of the "gcc"
with "gcc32". It finally compiled, but when I tried to use the module
it didn't work right. I had software I had written and been using for
months that used this module. Now suddenly it wasn't working. I
narrowed it down to the Mad library getting "stuck." Essentially,
either the code compiled from "Audio::Mad" wasn't working, or the
combination of the gcc4 "libmad" code coupled with the gcc32 code of the
"Audio::Mad" module just didn't get along. It rendered my software
What is my software? It's a Perl based media manager / player, video
game server etc. It's something I intend to put in my car eventually.
It utilizes SDL and many other libraries. The Audio::Mad library is
what I use to play MP3's in the software. It all worked magnificently
in FC3. It just sits there in FC4.
Usually I'm able to fix minor problems in C code, but this stumped me.
The XS code (where the gcc4 compiler complained) read like Greek to me.
Once again, thank you for your intelligent explanations and questions.
I appreciate it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users