Re: LYNX-DEV Lynx version 2.7 compilation problem (SCO Unix)

[T.E.Dickey]

> > (or new ones which perhaps have old headers unreplaced).  Nothing short
> > of physically replacing remove() calls with unlink() calls appeared to
> > work in that particular case.  Otherwise, they still get the error
> > message about "__UNLINK", which is an external symbol, not in the
> > Lynx code.
> 
> On the contrary. Linking the extra module
> 
> SCOcrud.c
> 
> int remove(const char *path)
> {
>       return unlink(path);
> }
> 
> with the right includes will do the job nicely
I considered that, too.  However, I've found that there can be subtle
problems with making a name that might later link with conflicts to a
shared library.  (I've had more than one dynamic loader silently create
malfunctioning programs this way).  Making a wrapper with a non-conflicting
name _looks_ more clumsy/ugly, etc., but is more reliable.

-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;