Bug 1225

Summary:	Buildroot fails to account for "nof" subdirectory (no floating point)
Product:	buildroot	Reporter:	gnemesure <gnemesure>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED FIXED
Severity:	normal	CC:	buildroot
Priority:	P5
Version:	unspecified
Target Milestone:	2010.05
Hardware:	PC
OS:	Linux
Host:		Target:
Build:
Attachments:	Buildroot .config file demonstrating libgcc_s issue

Description gnemesure 2010-03-02 20:25:45 UTC

I am using buildroot-2010.2 to target a 440GP processor with no hardware floating point.

When software floating point is enabled (BR2_SOFT_FLOAT), the gcc build puts libgcc_s.so, libstdc++.so, etc. in an "nof" subdirectory that buildroot is not accommodating. These are deposited in

   $(STAGING_DIR)/usr/powerpc-linux-uclibc/lib/nof

but the toolchain/gcc/gcc-uclibc-4.x.mk makefile tries to copy these files from

   $(STAGING_DIR)/usr/powerpc-linux-uclibc/lib

which results in failure to copy the libraries to the target filesystem.

This is with GCC 4.3.4. I'm not sure if this applies to other versions as well.

As a workaround, I think I can enable floating point in the kernel, and then enable hardware floating point in the toolchain.

Comment 1 Thomas Petazzoni 2010-03-02 21:50:35 UTC

I am not able to reproduce, with a build for PowerPC 440, BR2_SOFT_FLOAT=y. So, something else must be different in your configuration. Could you attach your .config ?

Note that your workaround is not very nice, since floating point emulation by the kernel is noticably slower that emulation in userspace.

Comment 2 gnemesure 2010-03-03 15:05:46 UTC

Created attachment 1189 [details]
Buildroot .config file demonstrating libgcc_s issue

Comment 3 gnemesure 2010-03-03 15:11:48 UTC

(In reply to comment #1)
> I am not able to reproduce, with a build for PowerPC 440, BR2_SOFT_FLOAT=y. So,
> something else must be different in your configuration. Could you attach your
> .config ?
> 

I've attached a .config file that should demonstrate the issue. I think it may depend on the specific version of binutils selected.

> Note that your workaround is not very nice, since floating point emulation by
> the kernel is noticably slower that emulation in userspace.
> 

Yes, I assumed that would be the case. However, floating point computation is not really central to my application, so this approach should be sufficient for now.

Thanks.

Comment 4 Thomas Petazzoni 2010-03-03 16:06:24 UTC

Ok, thanks, got it. I think I missed it the previous time because the error is ignored and the build continues:

==================================================================

# These are in /lib, so...
rm -rf /home/test/buildroot/output/target/usr/lib/libgcc_s*.so*
cp -dpf /home/test/buildroot/output/staging/usr/powerpc-linux-uclibc/lib*/libgcc_s* \
                /home/test/buildroot/output/target/lib/
cp: cannot stat `/home/test/buildroot/output/staging/usr/powerpc-linux-uclibc/lib*/libgcc_s*': No such file or directory
make: [/home/test/buildroot/output/stamps/gcc_libs_target_installed] Error 1 (ignored)
/home/test/buildroot/output/staging/usr/bin/powerpc-linux-uclibc-strip --remove-section=.comment --remove-section=.note --strip-unneeded /home/test/buildroot/output/target/lib/libgcc_s*
/home/test/buildroot/output/staging/usr/bin/powerpc-linux-uclibc-strip: '/home/test/buildroot/output/target/lib/libgcc_s*': No such file
make: [/home/test/buildroot/output/stamps/gcc_libs_target_installed] Error 1 (ignored)
mkdir -p /home/test/buildroot/output/target/usr/lib
cp -dpf /home/test/buildroot/output/staging/usr/powerpc-linux-uclibc/lib*/libstdc++.so* \
                /home/test/buildroot/output/target/usr/lib/
cp: cannot stat `/home/test/buildroot/output/staging/usr/powerpc-linux-uclibc/lib*/libstdc++.so*': No such file or directory
make: [/home/test/buildroot/output/stamps/gcc_libs_target_installed] Error 1 (ignored)

==================================================================

Comment 5 gnemesure 2010-03-03 23:15:53 UTC

The use of an "nof" subdirectory is to support the multilib capability enabled by BR2_ENABLE_MULTILIB. When this is disabled, the "nof" directory is not used, and the original problem does not occur.

Probably need to check this flag in the gcc-uclibc-*.mk makefile.

Comment 6 Thomas Petazzoni 2010-07-29 19:27:28 UTC

This bug is "fixed" by the fact that we don't allow multilib toolchain builds anymore, since http://git.buildroot.net/buildroot/commit/?id=5575d205c35942d992db636a4f7caa246340bd0c