Any news on this libc_hidden_def issue?
Thx,
Alain
On Thursday 29 May 2003 12:20, Alain Knaff wrote:
> Hello,
>
> 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,
>
> Alain
_______________________________________________
zlibc mailing list
zlibc(a)tux.org
http://www.tux.org/mailman/listinfo/zlibc
Base install of RH8 has glibc 2.0
I get a file not found now. Any solution? Works perfectly fine with RH7.2 base install standard glibc on that machine.
Help?
Paul
