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.

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

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...

[--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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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