Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 May 1998 16:46:24 -0600
From:      Nate Williams <nate@mt.sri.com>
To:        joelh@gnu.org
Cc:        nate@mt.sri.com, rnordier@nordier.com, eivind@yes.no, current@FreeBSD.ORG
Subject:   Re: Fix for undefined "__error" and discussion of shared object versioning
Message-ID:  <199805282246.QAA21766@mt.sri.com>
In-Reply-To: <199805282201.RAA00542@detlev.UUCP>
References:  <199805271551.RAA11565@ceia.nordier.com> <199805281829.NAA01253@detlev.UUCP> <199805281941.NAA20236@mt.sri.com> <199805282024.PAA01692@detlev.UUCP> <199805282047.OAA20525@mt.sri.com> <199805282201.RAA00542@detlev.UUCP>

next in thread | previous in thread | raw e-mail | index | archive | help
> >>>> My own concern would be the amount of code in third-party programs
> >>>> that uses gccisms.
> >>> Very few programs *should* use gccisms.  If they do, they are broke
> >>> since they won't build on other OS's compilers.
> >> Not necessarily; ifdef's are common:
> >    #ifndef __GCC__
> >    #define inline
> >    #endif
> > So it's a non-issue.
> 
> Not if I want inline code.

Your program will work 'the same' if the code isn't inlined.  It'll just
run faster, since most of the time inlining busts the cache. :)

> >> I'm not discussing what should be, I'm discussing what is.  We have a
> >> good percentage of software from the Linux camps, and many of their
> >> software authors wouldn't know a non-portable construct if it walked
> >> up and introduced itself in assembly code.
> > Fine, very little of that code is in our tree, including the ports
> > tree.  Most of the stuff that matters is commercial and we don't get
> > access to the source and run it under emulation.
> 
> Matters?  Matters to whom?  The only commercial app I myself run is
> Allegro.

Which Linux programs do you run under FreeBSD that will only compile
with GCC?

> > smaller,
> 
> Nice, but with today's hardware, smaller for the sake of being smaller
> is less and less of a factor.

Smaller == easier to fix bugs/maintain.  Bloat because we can is still
bloat, and it means the program is un-necessarily complex for no *real*
good.

> > easier to maintain,
> 
> Can't speak to that, haven't tried.

Have tried, gave up.  Too much investment is required for little gain.



Nate

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805282246.QAA21766>