Thank you Burton and Tanu. The upshot here seems to be that there is a platform dependency on whether one links to libgcc_s.a or libgcc_s.so.1:
"libgcc.a or libgcc_s.so.1 on some platforms”. I suspect that my test program, which was supplied to me as a .deb package, was compiled on Ubuntu, and so links to libgcc_s.so.1. I can’t see any obvious way to get libgcc_s.so.1 on Yocto. I already have: IMAGE_INSTALL_append = " gcc g++ binutils libgcc libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev \ autoconf automake ccache chkconfig glib-networking glibmm \ packagegroup-core-buildessential pkgconfig \ boost cmake zlib glib-2.0 net-snmp \ …” That leads me to think that the program I am testing needs to be compiled specifically on Yocto also. That conclusion seems a bit unusual to me in a Linux context, though obviously not unheard of. Regards Nathan > On 5 Feb 2016, at 12:59, Burton, Ross <ross.bur...@intel.com> wrote: > > > On 5 February 2016 at 11:40, Nathan Sowatskey <nat...@nathan.to> wrote: > Is there a way to get the libgcc_s library on a Yocto image? Is that even the > right thing to do? > > It's fairly likely that your binary is actually linking to libgcc_s.so.1 > (which by default is in /lib, part of libgcc). libgcc_s.so is the > development-time-only symlink so that's packaged into libgcc-dev. You'll > only need that on your target if you want to compile on it. > > Ross -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
