On Sun, Jun 15, 2014 at 11:05 PM, Jacob Kroon <[email protected]> wrote:
> (I've stripped all paths in the mail from the OE build directory) > > Running > > > sysroots/x86_64-linux/usr/bin/x86_64-oesdk-mingw32.gcc-crosssdk-initial/x86_64-oesdk-mingw32-gcc > -print-search-dirs > > I see that it is looking for objects in (amongst other things): > > > sysroots/x86_64-nativesdk-mingw32-oesdk-mingw32/mingw/lib/x86_64-oesdk-mingw32/4.8.2/ > sysroots/x86_64-nativesdk-mingw32-oesdk-mingw32/mingw/lib/ > > If I add a symlink in sysroots/x86_64-nativesdk-mingw32-oesdk-mingw32 > > ln -s usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/ mingw > > bitbaking meta-toolchain succeds, and I get a cross-canadian gcc, > arm-oe-linux-gnueabi-gcc.exe > > Grep:ing for "mingw/lib" in gcc-4.8.2 sources, I get hits in: > > configure.ac <http://configure.ac>: > FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L${prefix}/${target}/lib > -L${prefix}/mingw/lib > gcc/config/i386/mingw32.h:#define STANDARD_STARTFILE_PREFIX_1 > "/mingw/lib/" > > Should any of these lines be patched to point to a user-supplied path ? If > not, could > any of you give a hint to where I should be digging instead ? > > I see now that this problem has already been fixed in oe-core master, and just needs a backport to daisy. db44be06c75f2ac17a55dd1764471e869e872b8b gcc: Clean up configure_prepend and fix for mingw Sorry for the noise. /Jacob
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
