Re: [PATCH 1/1] Add multilib build support for libc target. Libc is build <multilib>-times in seperate sysroot directories. In a last step links are created to reflect the expected multilib structure.

["konrad.gaisler" <konrad at gaisler dot com>]

On 12/26/2011 05:56 PM, Yann E. MORIN wrote:
> Konrad, All,
>
> On Saturday 24 December 2011 22:11:43 konrad.gaisler wrote:
> [--SNIP--]
> > Is it possible that I missed something here? I think the
> > first patch I sent included this lines:
> >
> > do_libc_start_files() {
> [--SNIP--]
> > }
> Indeed, this was missing in your first and second patches:
>      http://sourceware.org/ml/crossgcc/2011-11/msg00029.html
>      http://sourceware.org/ml/crossgcc/2011-11/msg00040.html
>
> I now have a better understanding of what is required, and where it is.
> Thanks!
>
> > The point here is that glibc's install process adds the /lib at the
> > end, however the multilib structure must have /lib before:
> > /lib/<multilib>. Adding these symlinks before makes the
> > libraries end up in the right place. The "rearrange" stage
> > then fixes up the wrong paths.
> > Hope that makes it more clear.
> That I understood, the part that was misleading was the missing hunk
> in do_libc_start_files.
>
> [--SNIP--]
> > > > +                               cat ${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i | ${sed} -r -e "s/\/lib\/$l/\/lib\/$bdir\/$l/g">   ${CT_SYSROOT_DIR}/${d}/${l}.so
> > > With this sed expression, you are not rewriting the dynamic linker path,
> > > which means a multilib variant still uses the default "ld.so".
> > You might be right. My particular toolchain doesnt care as for the
> > ld.so probably doesnt differ. It is also so that in the final running
> > embedded-system, there is only one libc set, that is copied back
> > to /usr/lib.
> That is something we'll have to check later: is it possible to have more
> than one multilib running on the target? I believe that would need some
> non-trivial hackery to work properly...
No, not multiple multilibs, but one of the multilibs subdirs. For example
for the leon-sparc toolchain, the toolchain would have 4 subdirs: ./ 
msoft-float/
mv8 and mv8/msoft-float.
on hardware without fpu but mv8 you would  only copy and use the
mv8/msoft-float multilib-subdir  at /usr/lib, the others will not be used.
-- Konrad

> [--SNIP--]
> > > In the end, it leaves everything in "sysroot/${dir}".
> > > It would make much more sense to carefully move the libs in their correct
> > > place, that is:
> > >    - move everything from "sysroot/${dir}/lib"     ->   "sysroot/lib/${dir}"
> > >                       and "sysroot/${dir}/usr/lib" ->   "sysroot/usr/lib/${dir}"
> > >    - get rid of "sysroot/${dir}" alltogether
> > >
> > > That's because gcc will search for things in "sysroot/{usr/,}lib/${dir}/",
> > > not in "sysroot/${dir}/{usr/,}lib/"
> > I'm not an insider to glibc, but maybe there is a option to
> > glibc's configure that create the right multilib structure.
> > Then all the hustle with moving and or creating symbolic
> > links  would be unneeded.
> Anyway, with the missing part you added above, it is more clear what you
> were trying to achieve.
>
> [--SNIP--]
> > > Floats are not the only thing we have to account for. For example, some
> > > archs can define big/little multilib. And most probably other stuff
> > > as well...
> > Sorry, I dont really know the requirements for other archs, I
> > come up with this because I require for sparc glibc the --with-fp=no.
> Yep, I was just saying ;-)
>
> Regards,
> Yann E. MORIN.


--
For unsubscribe information see http://sourceware.org/lists.html#faq