Re: How to override "hidden symbols" from a preloadable object (LD_PRELOAD)
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@tux.org http://www.tux.org/mailman/listinfo/zlibc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alain Knaff wrote:
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?
It's not only bad ettiquette, it's completely invalid to assume anything about the implementation of the C library. Intercept incoming calls to your heart content and at your own risk, but once a call entered libc it's non of your business how it works. - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+8slw2ijCOnn/RHQRAlJKAJwJDSh7fUjDV2JsDL58YcdGYAPKhQCeIQ07 SALQiIMLfTXEdgnIceuKVuk= =Gghg -----END PGP SIGNATURE----- _______________________________________________ zlibc mailing list zlibc@tux.org http://www.tux.org/mailman/listinfo/zlibc
Alain, that answer is pretty harsh. I hope you find an answer. In the meantime, I'm going to write wrappers that call gzip individually for the programs that used to use the zlibc library. Perhaps the other developer will be nicer than Ulrich and give you a solution that doesn't "get them bent out of shape". Paul ----- Original Message ----- From: "Ulrich Drepper" <drepper@redhat.com> To: "Alain Knaff" <alain@knaff.lu> Cc: <jakub@redhat.com>; "Paul Murray" <pjmurray@tfb.com>; <zlibc@tux.org> Sent: Friday, June 20, 2003 1:44 AM Subject: Re: How to override "hidden symbols" from a preloadable object (LD_PRELOAD)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alain Knaff wrote:
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?
It's not only bad ettiquette, it's completely invalid to assume anything about the implementation of the C library. Intercept incoming calls to your heart content and at your own risk, but once a call entered libc it's non of your business how it works.
- -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+8slw2ijCOnn/RHQRAlJKAJwJDSh7fUjDV2JsDL58YcdGYAPKhQCeIQ07 SALQiIMLfTXEdgnIceuKVuk= =Gghg -----END PGP SIGNATURE-----
_______________________________________________ zlibc mailing list zlibc@tux.org http://www.tux.org/mailman/listinfo/zlibc
On Saturday 21 June 2003 01:03, Paul Murray wrote:
Alain, that answer is pretty harsh.
Indeed. Given from that answer, I see no "clean" way of makeing zlibc to correctly work with glibc...
I hope you find an answer.
The only possibility might be to go back to binary patching libc, as was done in the old days with a.out libs. Not a pretty thought.
In the meantime, I'm going to write wrappers that call gzip individually for the programs that used to use the zlibc library.
Perhaps the other developer will be nicer than Ulrich and give you a solution that doesn't "get them bent out of shape".
Let's hope...
Paul
Regards, Alain _______________________________________________ zlibc mailing list zlibc@tux.org http://www.tux.org/mailman/listinfo/zlibc
participants (3)
-
Alain Knaff -
Paul Murray -
Ulrich Drepper