[uClibc] close replaced w/ __libc_close

Manuel Novoa III mjn3 at codepoet.org
Thu Oct 28 19:45:53 UTC 2004


Hi Peter,

First, regarding part of your previous patch...

> diff -urN uClibc-0.9.26.orig/include/unistd.h
> uClibc-0.9.26/include/unistd.h
> --- uClibc-0.9.26.orig/include/unistd.h 2004-10-28 14:37:47.000000000
> +0200
> +++ uClibc-0.9.26/include/unistd.h      2004-10-28 15:18:10.000000000
> +0200
> @@ -302,6 +302,9 @@
>  /* Read NBYTES into BUF from FD.  Return the
>     number read, -1 for errors or 0 for EOF.  */
>  extern ssize_t read (int __fd, void *__buf, size_t __nbytes) __THROW;
> +#ifdef _LIBC
> +extern ssize_t __libc_read (int __fd, void *__buf, size_t __nbytes) __THROW;
> +#endif

I don't want to see special-case cruft added to the general headers.
Also, the __libc_read replacement is just a single instance of a larger
problem.  I'd eventually like to supply hidden alias symbols for lots
of functions called by the library internally, and would much rather
see an internal header (or group of them) used for the prototypes.

On Thu, Oct 28, 2004 at 06:50:42PM +0200, Peter S. Mazinger wrote:
> All except stdio are done (again as before, I can't understand 
> __gcs.close, so do not know what to do)

gcs is my abbreviation for "glibc custom stream".  If custom streams
are enabled in the uClibc configuration, then read, write, seek,
and close are accessed indirectly.  Otherwise they are referenced
directly.  See the related macros in stdio/_stdio.h and the functions
in stdio/_cs_stdio.c.

> I have seen the __attribute_hidden__ addition to cvs.
> 
> If we want to hide __libc_* using visibility=hidden, then this can be 
> done, as I understand it, only if they are used exclusively in libc.
> 
> If this is the intention for the future, then only those parts of the 
> patches should be applied, that do not influence libutil/libresolv....

The intention is to start using hidden symbols, as well as to use
export maps when building the shared libs.

Also, regarding the transition to using hidden symbols internally,
I'd rather not apply a patch per function.  That's just going to add
lots of noise to the cvs logs.  Personally, I'd rather see the changes
go in all at once.

Manuel



More information about the uClibc mailing list