Re: FC4 good new tech, bad legacy support

From: Richard Kelsch (rich_at_csst.net)
Date: 06/29/05

  • Next message: Alexander Dalloz: "Re: Layer 7 filtering" 
    Date: Wed, 29 Jun 2005 13:23:42 -0700
To: For users of Fedora Core releases <fedora-list@redhat.com>

    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 

    


    -- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
  • Next message: Alexander Dalloz: "Re: Layer 7 filtering"

    Relevant Pages

    • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
      ... what experienced programmers do, ... optimization, ... Thugs" ad nauseum fits that a lot more closely than discussing compiler ... be modified outside a loop, and guessing ...
      (comp.programming)
    • Re: Statement on Schildt submitted to wikipedia today
      ... to working programmers and more with being "right all the time, ... so that compiler developers could be shed ... The major corporate interests were compiler developers, ... processors, committed to standard division semantics, and otherwise ...
      (comp.lang.c.moderated)
    • Re: Interesting article by Randall Hyde
      ... as you are the compiler optimization "expert". ... of the work that has gone into creating optimizing compilers. ... > Compilers generate better code than *most* programmers all of the ... learn without needing to know anything about assembly language. ...
      (comp.lang.asm.x86)
    • Re: Integer types in embedded systems
      ... Notice the integer type I've used, ... compilers for 8-bit micros have an option for telling the compiler not ... Most C programmers these days are woefully ignorant, ... At least as important as portability, ...
      (comp.lang.c)
    • Re: [PHP] Extracting Source code from Binary Files(.dll,.exe.,class)
      ... assembly language and Programmers who have written ... an assembly Language Expert) say on Unix or Windows then why not he will be ... Extracting Source code from Binary ... This is dependent upon the compiler (.obj files from ...
      (php.general)
    Loading