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

[Carl Miller <chaz at energoncube dot net>]

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.  Now I've got what seems, comparatively to me,
a stupid question, but I'll ask it anyway....

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


(*1) One uncovered a bug in the uClibc headers; another indicated the need
to create a uclibc directory underneath libstdc++v3/config/os in gcc.

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