FC4 good new tech, bad legacy support

[Richard Kelsch]

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 
useless.

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.

Rich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050629/b2a67103/attachment-0001.htm>