crosstool /lib/nof libraries copied back to /lib?

[Dan Kegel]

Carl Miller wrote:
> After multiple hairy C++ issues (*1), I've finally got a build of
> powerpc-405-linux-uclibc to get to the end of the final gcc "make all
> install" using crosstool. 

Woo-hoo!

> On my last run, the crosstool build failed here:
> -----
> If the chip does not have a floating point unit, and there are shared libraries in /lib/nof, copythem to lib
> We check GLIBC_EXTRA_CONFIG (--without-fp) to see if it contains --without-fp to decide.
> cp: cannot stat `/home/cnmiller/tools/powerpc405-linux-uclibc/powerpc-405-linux-uclibc/lib/nof/*.so*': No such file or directory
> -----
> Indeed, my /lib/nof directory contains only the following five files:
> libiberty.a  libstdc++.a  libstdc++.la  libsupc++.a  libsupc++.la
> 
> So the questions:
> 1) Why only copy shared libraries?  Does ld look in /lib/nof, but ld.so
>    doesn't?  Would it make more sense to copy the static libraries
>    directly to /lib as well?  If the target truly has no FPU, why keep
>    the versions that need one around at all?
> 2) It seems like non-existence of shared libraries in /lib/nof should
>    not be a fatal error.  Opinions?
> 3) I find it a little distasteful to be using a variable defined to hold
>    glibc options to decide how to handle something that's purely part of
>    gcc.  The potential for confusion is compounded now that there's a
>    patch to add newlib support to crosstool, and there's very nearly one
>    to add uclibc support.  Should we:
>    a) Specify no-FPU in the gcc extra config options variable in a way that
>       crosstool can easily pull it out for this test?  (...bearing in mind
>       that this may require filtering out that flag before appending the
>       contents to gcc's configure.)
>    b) Pull out no-FPU as a crosstool-global option, and have crosstool.sh
>       insert it into each component's configuration for you as necessary?
>    c) Something else?  Open to suggestions.

Carl, this is the ragged edge of crosstool.  I didn't really have
time to understand how to deal with multilibbing; I just did a hack
that worked for the ppc405, and wrote it in a way that looked general.
That might have been a mistake.  It'd be fine if you changed
the behavior here, possibly introducing an explicit "HACK_TO_COPY_NOF_TO_TOP"
variable to be set by the user if they need that kludge.
- Dan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com