|
From: <sv...@va...> - 2005-11-10 00:40:30
|
Author: dirk Date: 2005-11-10 00:40:26 +0000 (Thu, 10 Nov 2005) New Revision: 5060 Log: we don't need libc. so don't link it Modified: trunk/Makefile.core.am trunk/Makefile.tool.am Modified: trunk/Makefile.core.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/Makefile.core.am 2005-11-09 16:32:02 UTC (rev 5059) +++ trunk/Makefile.core.am 2005-11-10 00:40:26 UTC (rev 5060) @@ -36,7 +36,7 @@ =20 include $(top_srcdir)/Makefile.flags.am =20 -PRELOAD_LDFLAGS_COMMON =3D -shared -Wl,-z,interpose,-z,initfirst +PRELOAD_LDFLAGS_COMMON =3D -nostdlib -shared -Wl,-z,interpose,-z,initfir= st PRELOAD_LDFLAGS_X86_LINUX =3D $(PRELOAD_LDFLAGS_COMMON) @FLAG_M32@ PRELOAD_LDFLAGS_AMD64_LINUX =3D $(PRELOAD_LDFLAGS_COMMON) -m64 PRELOAD_LDFLAGS_PPC32_LINUX =3D $(PRELOAD_LDFLAGS_COMMON) Modified: trunk/Makefile.tool.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/Makefile.tool.am 2005-11-09 16:32:02 UTC (rev 5059) +++ trunk/Makefile.tool.am 2005-11-10 00:40:26 UTC (rev 5060) @@ -61,7 +61,7 @@ $(TOOL_LDFLAGS_COMMON) \ -Wl,-T,$(top_builddir)/valt_load_address_ppc32_linux.lds =20 -PRELOAD_LDFLAGS_COMMON =3D -shared -Wl,-z,interpose,-z,initfirst +PRELOAD_LDFLAGS_COMMON =3D -nostdlib -shared -Wl,-z,interpose,-z,initfir= st PRELOAD_LDFLAGS_X86_LINUX =3D $(PRELOAD_LDFLAGS_COMMON) @FLAG_M32@ PRELOAD_LDFLAGS_AMD64_LINUX =3D $(PRELOAD_LDFLAGS_COMMON) -m64 PRELOAD_LDFLAGS_PPC32_LINUX =3D $(PRELOAD_LDFLAGS_COMMON) |
|
From: Julian S. <js...@ac...> - 2005-11-10 00:47:36
|
> we don't need libc. so don't link it This is for the preload libraries, right? Not the main executable (libc for that disappeared some time back). Are you 100% sure of this -- for example, that there will be no bad interaction the preloads needing gcc helper functions like __udivdi3 ? I guess those come from libgcc and not glibc. J |
|
From: Tom H. <to...@co...> - 2005-11-11 10:59:10
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> we don't need libc. so don't link it
>
> This is for the preload libraries, right? Not the main executable
> (libc for that disappeared some time back).
>
> Are you 100% sure of this -- for example, that there will be no
> bad interaction the preloads needing gcc helper functions like __udivdi3 ?
> I guess those come from libgcc and not glibc.
Well strictly speaking vgpreload_core.so does need glibc as it's whole
purpose in life is to find __libc_freeres.
The reason it is still working is that glibc is normally loaded anyway
so the symbol can be resolved. Statically linked programs ignore the
preload anyway, so the only problem would be a dynamically linked
program that didn't link with glibc or did so statically.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-11-11 12:46:50
|
On Friday 11 November 2005 11:59, Tom Hughes wrote: > The reason it is still working is that glibc is normally loaded anyway > so the symbol can be resolved. Statically linked programs ignore the > preload anyway, so the only problem would be a dynamically linked > program that didn't link with glibc or did so statically. How are you able to find the __libc_freeres symbol if a program links statically against glibc? The symbol information is usually then not exported (at least when its a stripped binary). Well, I'm fine with reverting the patch if you think it fixes an issue, but it makes binary packages require both glibc's (not a big issue though). Dirk |
|
From: Tom H. <to...@co...> - 2005-11-11 13:27:12
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Friday 11 November 2005 11:59, Tom Hughes wrote:
>
>> The reason it is still working is that glibc is normally loaded anyway
>> so the symbol can be resolved. Statically linked programs ignore the
>> preload anyway, so the only problem would be a dynamically linked
>> program that didn't link with glibc or did so statically.
>
> How are you able to find the __libc_freeres symbol if a program links
> statically against glibc? The symbol information is usually then not exported
> (at least when its a stripped binary).
A fully statically linked program will not use ld.so so will
ignore LD_PRELOAD and never load vgpreload_core.so anyway.
If it is statically linked against glibc but has other dynamic
dependencies then there is an issue but I failed to create such
a case so far because I haven't found a way to create shared
library that doesn't drag in glibc...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|