libtool
[Top][All Lists]
Advanced

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

Re: ltdl.c and 1.4.1 (type conflicts)


From: Gary V. Vaughan
Subject: Re: ltdl.c and 1.4.1 (type conflicts)
Date: Thu, 13 Sep 2001 21:48:02 +0100
User-agent: Mutt/1.3.22.1i

On Wed, Sep 12, 2001 at 11:22:38AM -0700, Bruce Korb wrote:
> Tim Mooney wrote:
> 
> > Something similar to what's done on page 147 (section 6.7) of K&R2e --
> 
> K&R2e == ANSI

You mean the 2nd edition of the Kernighan and Ritchie book describes
ANSI C?  I didn't know that.

> > Of course, most of the functions still use the K&R style arg definitions.
> 
> K&R1e.
> 
> > Maybe it should be switched to using ANSI only, and people should be advised
> > to use `ansi2knr' if they need to compile libtool with a pre-ANSI compiler.
> > This may not sit well with the gcc people, as we may get into a
> > chicken-or-the-egg problem there.  I don't know.
> 
> At some point, even the GCC folks will have to accept the fact that
> K&R1e is a hobbiest-only anacronsism.  Anyone devoted to supporting
> a box without an ANSI compiler for bootstrapping is, perforce, a
> hobbiest.  I don't think squandering developer time for supporting
> zero-gain platforms is a prudent use of resources.  They are not
> "free", even if the open source community does not pay actual money.
> It is, instead, a lost opportunity cost.

Plenty of UNIX vendors have unbundled their ANSI compiler in favour of
a minimal K&R compiler for kernel module tweaking.  Supporting K&R is
really not that hard... for bootstrap level tools there is almost no
gain in ripping out the existing support, and the risk of reducing the
number of architectures that can compile GCC.  When maintaining C code
that is portable to hundreds of versions of vendor libc, using a few
macros to retain K&R support is the least of your worries!

I would argue that using your vendor compiler, linker, make utility
and C library is a hobbiest-only anachronism when all are available,
in binary form for all the important architectures in service
nowadays.  Coding would be so much faster and more straight forward if
we didn;t have to think about vendor inadequacies...  In fact we
wouldn't even need Autoconf, Automake or Libtool!  But if I used that
argument, people would think I was being facetious, so I'll shut up.
;-)

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]