public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: "konrad.gaisler" <konrad@gaisler.com>
To: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Cc: crossgcc@sourceware.org
Subject: 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.
Date: Sat, 24 Dec 2011 21:10:00 -0000	[thread overview]
Message-ID: <4EF6400F.8060400@gaisler.com> (raw)
In-Reply-To: <201112240022.18409.yann.morin.1998@anciens.enib.fr>

 >From what I see it does absolutely nothing, because ...
>> +           dir="${i%%;*}"
>> +          bdir="$(echo ${dir} | ${sed} -r -e 's:/:\\\\/:g')"
>> +           if [ "${dir}" != "." ]; then
>> +               flags="$(echo $i | ${sed} -r -e 's/^[^;]*;//' -e 's/@/ -/g')";
>> +               CT_DoStep DEBUG "Fixing up multilib location ${CT_SYSROOT_DIR}/${dir}/lib to ${CT_SYSROOT_DIR}/lib/${dir}"
>> +               mkdir -p ${CT_SYSROOT_DIR}/lib/${dir}
>> +               mkdir -p ${CT_SYSROOT_DIR}/usr/lib/${dir}
>> +
>> +               # recreate the symbolic links for multilib
>> +               for f in $(find ${CT_SYSROOT_DIR}/usr/lib/${dir}/ -type l -maxdepth 1); do
> ... of the 'find' here, that scans two newly-created directories (just
> above), so they are empty.
>
> Did you mean to scan "${dir}/usr/lib" and not "usr/lib/${dir}" ?
>
> And what about "${dir}/lib" ?

Is it possible that I missed something here? I think the
first patch I sent included this lines:

do_libc_start_files() {
     cross_cc=$(CT_Which "${CT_TARGET}-gcc")
     if [ "${CT_CC_MULTILIB}" = "y" ]; then
     for i in `${cross_cc} --print-multi-lib 2>/dev/null`; do
             dir=`echo $i | sed -e 's/;.*$//'`;
         if [ "${dir}" = "." ]; then
         true;
         else
         if [ "${CT_USE_SYSROOT}" = "y" ]; then
             # prepare installation redirects
             mkdir -p ${CT_SYSROOT_DIR}/${dir}/usr
             mkdir -p ${CT_SYSROOT_DIR}/lib/${dir}
             mkdir -p ${CT_SYSROOT_DIR}/usr/lib/${dir}
             ln -sf ${CT_SYSROOT_DIR}/usr/lib/${dir} 
${CT_SYSROOT_DIR}/${dir}/usr/lib
             ln -sf ${CT_SYSROOT_DIR}/lib/${dir} 
${CT_SYSROOT_DIR}/${dir}/lib
             fi
         flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`;
         CT_DoStep INFO "Installing C library start files multilibbed. 
Flags: ${flags} Dir: ${dir}"
         do_single_libc_start_files "/${dir}" "${flags}"
         CT_EndStep
         fi
     done;
     fi
     do_single_libc_start_files
}

These symlinks that are installed before the glibc
installs make that
${CT_SYSROOT_DIR}/${dir}/usr/lib
end up in
${CT_SYSROOT_DIR}/usr/lib/${dir}
and
${CT_SYSROOT_DIR}/${dir}/lib
end up in
${CT_SYSROOT_DIR}/lib/${dir}

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.

The whole thing might have to be rewritten, I think
you might come up with a solution that is easier.


>
> Besides, the options ordering to the 'find' command is wrong, and 'find'
> complains loudly. No problem, fixed here.
>
>> +                   fn=`basename $f`
>> +                   ln=`readlink $f`
>> +                   ln=`basename $ln`
>> +		   # go toward root. Count the numer of "/" and asseble a "../.." prefix
>> +                   pre=$( echo ${dir} | awk '{r="";
>> +		       c=split($0,b,"/");
>> +		       for(i=0;i<c;i++){
>> +		           if(i!=0){r=r "/";}
>> +			   r=r "..";
>> +		       };
>> +		       printf("%s",r);
>> +		   }')
>> +		   CT_Pushd "${CT_SYSROOT_DIR}/usr/lib/${dir}/"
>> +                   ln -sf ../../${pre}/lib/${dir}/$ln $fn
>> +		   CT_Popd
>> +               done
>> +
>> +               # rewrite the library multiplexers
>> +               for l in libc libpthread libgcc_s; do
>> +                   for d in lib/${dir} usr/lib/${dir}; do
>> +                       if [ -f "${CT_SYSROOT_DIR}/${d}/${l}.so" -a ! -L ${CT_SYSROOT_DIR}/${d}/${l}.so ]; then
>> +                           if [ ! -f "${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i" ]; then
>> +                               cp ${CT_SYSROOT_DIR}/${d}/${l}.so ${CT_SYSROOT_DIR}/${d}/${l}.so_ori_i
>> +                               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. I think buildroot needs a patch to copy the right set
of libc though.

>
> I think the following sed-expr does the trick (and does not require
> the '/' mangling done above):
>      "s:/lib/:/lib/${dir}/:g;"
>
> (mangling ':' in ${dir} is not needed, the dirname can not contain a ':',
> as ':' is the multilib separator in "gcc -print-multi-lib").
>
>> +			   else
>> +			       CT_DoLog WARN "${CT_SYSROOT_DIR}/${d}/${l}.so has already been patched, skipping"
>> +                           fi
>> +                       fi
>> +                   done
>> +               done
>> +               CT_EndStep
>> +           fi
>> +        done;
> 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.

>
> Of course, we can go with the symlinks first; once that works, we can look
> into doing the move and clean-up.
>
> [--SNIP--]
>>       case "${CT_ARCH_FLOAT_HW},${CT_ARCH_FLOAT_SW}" in
>> -        y,) extra_config+=("--with-fp");;
>> +        y,) # if it is a<multilib>  build then check if -msoft-float is given
>> +	    if [ "x`expr "${extra_flags}" : '.*-msoft-float.*'`" != "x0" ]; then
>> +	    	extra_config+=("--with-fp=no");
>> +	    else
>> +	    	extra_config+=("--with-fp");
>> +	    fi
>> +	    ;;
>>           ,y) extra_config+=("--without-fp");;
>>       esac
> 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.

>
> Well... Time for some rejoicing !
> Merry X-Mas to All, and a Happy New Year! Cheers !

Merry XMas back. It just has passed.
-- Konrad
>
> Regards,
> Yann E. MORIN.
>


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

  reply	other threads:[~2011-12-24 21:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14 10:45 Konrad Eisele
2011-12-12 23:07 ` [PATCH 1/1] Add multilib build support for libc target Yann E. MORIN
2011-12-13  8:38   ` Konrad Eisele
2011-12-13 17:15     ` Yann E. MORIN
2011-12-23 23:22 ` [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
2011-12-24 21:10   ` konrad.gaisler [this message]
2011-12-26 16:57     ` Yann E. MORIN
2011-12-26 19:03       ` konrad.gaisler
2011-12-26 21:30         ` Yann E. MORIN
2011-12-26 17:29     ` Yann E. MORIN
2011-12-27 23:57   ` [PATCH 1/1] Add multilib build support [...] Yann E. MORIN
2011-12-31 18:01   ` Yann E. MORIN
2012-01-02  7:17     ` konrad.gaisler
  -- strict thread matches above, loose matches on Subject: below --
2011-11-14 10:38 simple multilib option Konrad Eisele
2011-11-14 10:55 ` [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 Eisele

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=4EF6400F.8060400@gaisler.com \
    --to=konrad@gaisler.com \
    --cc=crossgcc@sourceware.org \
    --cc=yann.morin.1998@anciens.enib.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).