Re: FC4 good new tech, bad legacy support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux