Re: [PATCH] acl attr libcap: mark shared libraries executable

[Mark Hatle <mark.hatle@windriver.com>]

On 6/14/13 3:53 AM, Burton, Ross wrote:
> On 14 June 2013 09:09,  <jackie.huang@windriver.com> wrote:
>> From: Jackie Huang <jackie.huang@windriver.com>
>>
>> While it is not necessary that shared libraries be executable,
>> if they are not marked as such bitbake will not examine them
>> for debug information.  So, we make them executable at the end of
>> installation.
>
> Wouldn't it be preferable to change the class that does the debug
> extraction so that it doesn't require executable bits on libraries?
> Fix the cause not the symptoms and all that.

I thought the class specifically looked for items in ${base_libdir} and 
${libdir} as well as executables elsewhere in the system.

We don't want to blindly scan and filter everything that is ELF, so the 
executable flag makes sense outside of the libdir.

from package.bbclass, split_and_strip_files:

     libdir = os.path.abspath(dvar + os.sep + d.getVar("libdir", True))
     baselibdir = os.path.abspath(dvar + os.sep + d.getVar("base_libdir", True))

         for root, dirs, files in cpath.walk(dvar):
             for f in files:

                 # Check its an excutable
                 if (s[stat.ST_MODE] & stat.S_IXUSR) or (s[stat.ST_MODE] & 
stat.S_IXGRP) or (s[stat.ST_MODE] & stat.S_IXOTH) \
                         or ((file.startswith(libdir) or 
file.startswith(baselibdir)) and ".so" in f):

                     if elf ...
                         add to list of files to split/strip

So the above iterates and checks if it is executable -or- lives in the libdir 
and baselibdir directory -and- contains '.so' in the name.

If this is not working, we need to fix it..  If this is working, but something 
later isn't, we need to fix that then.

It may be that the tool we're using (debugedit) requires the binaries to be 
executable, if that is the case then we'll need to capture the original perms, 
add executable, run debugedit and restore them.  But this will need some further 
investigation.

> Ross
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>