[Bug 225969] Merge Review: kernel

Roland McGrath roland at redhat.com
Tue Oct 26 18:33:20 UTC 2010


>  > kernel.x86_64: E: shared-lib-without-dependency-information
>  > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so
>  > kernel.x86_64: E: shared-lib-without-dependency-information
>  > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so
>  > kernel.x86_64: E: shared-lib-without-dependency-information
>  > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so
>  > kernel.x86_64: E: missing-PT_GNU_STACK-section
>  > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-syscall.so
>  > kernel.x86_64: E: missing-PT_GNU_STACK-section
>  > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso.so
>  > kernel.x86_64: E: missing-PT_GNU_STACK-section
>  > /lib/modules/2.6.36-1.fc15.x86_64/vdso/vdso32-int80.so
>  > 
>  > (I don't begin to claim that I understand what's happening here, but I suspect
>  > that these vdso files server a specific purpose and that these warnings do not
>  > apply to them.)
> 
> I'm going to assume this is to be expected, as they aren't 'real' libraries. Roland ?

Yes, they would be meaningless if they were there.  It would be ~harmless
(just sizeof(Elf{32,64}_Phdr bloat in the vdso image, fine as long as it
doesn't push it over another page) to add it to the vdso linker script,
but it would have no meaning whatsoever.

>  > kernel.x86_64: W: non-conffile-in-etc
>  > /etc/ld.so.conf.d/kernel-2.6.36-1.fc15.x86_64.conf
>  > 
>  > (Should this be marked as %config(noreplace)?)
> 
> it's versioned, so no ? I think ?

I don't really grok with %config(noreplace) means.  The file is indeed
versioned.  It only lives in /etc because /etc/ld.so.conf.d is where you
put things to get them seen by ldconfig.  It could as well be a symlink (of
that same name) to a file living somewhere else (in /lib/modules/V/vdso/ I
guess), if rpm rules like that better.

>  > kernel-devel.x86_64: E: zero-length
>  > /usr/src/kernels/2.6.36-1.fc15.x86_64/include/config/fb/via.h
>  > [ ... repeated for several hundred empty kernel .h files ... ]
>  > 
>  > (I assume that all of these zero length header files are kernel header files
>  > which are not intended to be exposed/exported to userspace. Perhaps it makes
>  > sense to iterate through the buildroot at the end of install and delete all of
>  > the zero length header files? Might speed up the -devel transaction.)
> 
> Something in the tree could be #include'ing them, but I don't see anything
> from a quick grep.  Not sure about this.  (They're autogenerated, and their
> content varies depending on CONFIG options being set).

They exist to embody the .config state.  I think you need all that stuff as
it is to build modules correctly.

> I think we can probably just kill all of these.

As long as you can definitely build a kernel module, including all the
kinds of modules systemtap ever wants to build, then sure.


Thanks,
Roland


More information about the kernel mailing list