Any news on this libc_hidden_def issue?
On Thursday 29 May 2003 12:20, Alain Knaff wrote:
> I'm the author of zlibc (http://zlibc.linux.lu), which is a
> preloadable object that allows applications to transparently read
> compressed data. No recompilation or relinking necessary.
> It works by overriding a number of key system calls (or rather, their
> libc entry points), such as open, stat, etc. in such a way that they
> check for .gz files if the file requested by the application did not
> exist, and then spawning a gunzip to uncompress the file.
> This has worked fine since the a.out days, until glibc-2.2, but
> recently broke in the glibc 2.3.
> From what I've seen, the reason for the problem are the
> libc_hidden_def macros which are now used throughout glibc. Their goal
> apparently is to make sure that libc functions (such as fopen or
> fopen64) only call libc's own functions (such as open), and to
> completely ignore any functions brought by LD_PRELOADed objects. As
> you can imagine, this breaks zlibc big time. Fopen will no longer call
> zlibc's "open" that checks for compressed files.
> Do you know of any method to have fopen still use the open supplied by
> zlibc? Or is it now considered "bad etiquette" to attempt to override
> libc's internal functions?
> Thanks for any ideas,
zlibc mailing list