Date: Tue, 19 Aug 2008 20:00:06 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: ports@freebsd.org, Jeremy Messenger <mezz7@cox.net> Subject: Re: best way to work around <malloc.h> vs <stdlib.h> ? Message-ID: <48AB1836.8060104@FreeBSD.org> In-Reply-To: <20080819184807.GA25850@onelab2.iet.unipi.it> References: <20080819172631.GA25160@onelab2.iet.unipi.it> <op.uf5bjbr19aq2h7@mezz.mezzweb.com> <20080819184807.GA25850@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 01:12:37PM -0500, Jeremy Messenger wrote: >> On Tue, 19 Aug 2008 12:26:31 -0500, Luigi Rizzo <rizzo@iet.unipi.it> wrote: >> >>> A fair amount of third party software in ports still uses <malloc.h> >>> which in our system is like this: >>> >>> /* $FreeBSD: src/include/malloc.h,v 1.5 2001/11/07 23:14:31 obrien >>> Exp $ */ >>> #if __STDC__ >>> #error "<malloc.h> has been replaced by <stdlib.h>" >>> #else >>> #include <stdlib.h> >>> #endif >>> >>> What is the best way to disable the error without an >>> explicit patch (there are over 200 patchfiles in ports >>> just doing that) ? >> I think patch it is best, because if I understand it corrects is that >> malloc() in stdlib.h is standard of ANSI C. Correct me if I am wrong. >> However, I don't see anything wrong with patch. You can simple use >> wildcard (*.c) or use find(1) to find files to replace the malloc.h -> >> stdlib.h by use REINPLACE_CMD without have to create multi-file patch. > > i am not questioning the correctness of using stdlib.h rather than malloc.h, > nor the fact that if the upstream is cooperating, one surely should pass patches > upstream. > > However this malloc.h (and missing sys/types.h -- there's another > 200+ patch files doing just that) seem to be very common porting > problem and so it would be issues and thought it could be nice to > find a fix that addresses those kind of problems. > > Wonder if a -I/usr/local/questionable-programs/include approach > could be used to wrap the handful of system headers that cause problems... It's a trivial fix. Just do it instead of over-engineering a solution :) Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AB1836.8060104>