Bug 160173
| Summary: | malloc intersept program is singularity behavior | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | KOSAKI Motohiro <kosaki.motohiro> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | drepper |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-06-13 07:49:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Static linking in Linux is meant primarily for system utilities that can't be linked dynamically (e.g. ldconfig, prelink) or some system recovery utilities. It is certainly not meant for use by 3rd party applications. Statically linked apps are usually less portable than dynamically linked ones (e.g. when they use NSS/iconv/locales), if you need to link some particular library statically, then -Wl,-Bstatic -lfoo -lbar -Wl,-Bdynamic is almost always a better solution. Some other operating systems don't support static linking at all for these reasons (e.g. Solaris). That said, you can override malloc even with -static, but you need to override the whole allocator, not just one selected function from it. So, if you decide to use different malloc, you should also use a different calloc, free, realloc, __libc_memalign at least, plus if your program uses other allocator functions (e.g. pvalloc, memaling, posix_memalign, mallinfo, etc., then those as well). When you link statically, you can't use dlsym (RTLD_NEXT, "malloc") etc. to provide your malloc implementation just as a wrapper on top of libc's allocator, and having malloc come from one allocator and free from another one means either that the program has no chance of working, or you rely on internal implementation details of libc's allocator. |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Description of problem: when below sample program compile, gcc different behaver with libc static or dynamic link. 1. gcc test.c -> ok. below program output "malloc called" 2. gcc test.c -static -> compile error! I think, this is bug. ------------------------- #include <stdio.h> void* malloc(size_t s){ printf("malloc called\n"); } main(){ malloc(1); } ---------------------------- Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: see description Actual Results: see sescription Expected Results: I think always output "malloc called", undisturbed libc linking model. and malloc is must interseptable because this is orthodox UNIX behaver. Additional info: