All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <poky@yoctoproject.org>
Subject: Re: Need some advice of how to get the ld.so names in multilib situation
Date: Fri, 29 Jul 2011 11:57:08 -0500	[thread overview]
Message-ID: <4E32E664.2020109@windriver.com> (raw)
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F2C40DBB269@shsmsx502.ccr.corp.intel.com>

On 7/28/11 10:20 PM, Lu, Lianhao wrote:
> Hi guys,
> 
> Bug #1236 http://bugzilla.pokylinux.org/show_bug.cgi?id=1236
> 
> In order to get ldd work under the multilib situation, ldd and ldconfig.h need
> to know all the full path names for all the dynamic loaders(ld.so) in the
> current multilib configuration. 
> 
> The dynamic loader's full path names would be something like:
>   ${base_libdir}/<ld.so name>
> 
> We can get the ${base_libdir} for each variant in the multilib configuration by
> setting the correct TUNE name. The problem resides in the <ld.so name>. For
> i586 and x86_32, the ld.so name would be "ld-linux.so.2"; for x86_64 it would
> be "ld-linux-x86-64.so.2"; but for other ABI, I see names like "ld-linux.so.3",
> "ld.so.1", "ld64.so.1", etc.
> 
> So the question is how we can get the correct ld.so names in the current
> multilib configuration? Hard code them in the TUNE configurations?

We can likely create a custom ldd and ldconfig.h (assuming it's only used by
ldconfig) machine package.  In this we can iterate over the multilibs configured
for the system and construct the necessary table of library paths.  (This is of
course way more complicated then just saying "the paths are here for this
architecture..."  but it seems to me that people want/require the flexibility to
change the library paths for their particular devices and distributions.

To iterate over it, we'll need to use python and then the base and multilib
values.. we can evaluate the ${libdir} and ${base_libdir} as necessary.  For the
individual ld.so names, those will need to be encoded into the libc itself.. the
tunes don't have the knowledge for the machine ABI -> ld.so mapping.

Then the table can be constructed something like (pseudo code, not python):

def so_mapping:
	if "i386" return "ld-linux.so.2"
	if "x86_64" return "ld-linux-x86-64.so.2"
	...

set multilib value to ""
so_name = so_mapping($TARGET_ARCH)
echo ${base_libdir}/${so_name} > list

for each multilib
 set OVERRIDES with multilib
 so_name = so_mapping($TARGET_ARCH)
 echo ${base_libdir}/${so_name} >> list
done

--Mark

> Best Regards,
> -Lianhao
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky



      reply	other threads:[~2011-07-29 16:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-29  3:20 Need some advice of how to get the ld.so names in multilib situation Lu, Lianhao
2011-07-29 16:57 ` Mark Hatle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E32E664.2020109@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=poky@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.