[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MiNT] gcc egcs to compile ttydev?
> -----Original Message-----
> From: Martin-Eric Racine [SMTP:q-funk@pp.fishpool.com]
> Sent: Friday, May 21, 1999 8:00 AM
> To: Jo Even Skarstein
> Cc: MiNT mailing-list
> Subject: Re: [MiNT] gcc egcs to compile ttydev?
>
> > > Actually, it's now becoming evident that _all_ libs (GEM, MiNT,
> socket)
> > > have been broken recently.
> >
> > I would say that if suddenly all your libs are "broken", it's most
> likely
> > a problem with your compiler or linker.
>
> *sigh* Jo, please read again.
>
> If I revert to MINTLIB 46, everything _always_ compiles fine,
> but newer libs don't always work. With any GCC/linker (of
>
Oh really? Since you're mainly compiling older sources from KGMD, has it
never occured to you that these sources may have been hacked/adapted to
deficiencies in older libs? I'm using a 0.50 beta right now, and most
*recent* sources compiles straight out of the box.
> If Juhani reverts to _older_ GEMLIB versions, CAB.OVL compiles
> well, but not using new versions:
>
This is because some symbols are renamed in recent GEMlibs. If you take a
look in the history-file or GEM.H you'll be able to update CAB.OVL in a
matter of seconds.
> The keyword is _previous_. Previous versions of the MINT/GEM libs
> produce good, small, usable binaries. Current ones broke some
> things along the line.
>
This is your point of view, I don't agree with you. Older sources are
adapted to older lib-versions, and these libs are simply not adequate today.
What do you want, an easy way to compile old stuff without changing
anything, or write portable code. CAB.OVL is a bad example here, as there
are a few hacks in there that's very dependant on the MiNTlib-version you
use. HYC is completely aware of it, but he preferes speed over portability.
Should we freeze the development of MiNTlibs because of such code?
The purpose with MiNTlibs is to be able to write portable code, and to
compile code from other platforms. This means that older, non-portable code
must be adapted over time. If you don't like this approach, simply use old
libs. It's not a big deal. I prefer to fix non-portable code instead of
crippling the libs.
Jo Even Skarstein