<div dir="ltr"><div>Hi Khem,<br><br></div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 13 September 2013 07:54, Khem Raj <span dir="ltr"><<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
On Sep 3, 2013, at 6:45 PM, Mark Hatle <<a href="mailto:mark.hatle@windriver.com">mark.hatle@windriver.com</a>> wrote:<br>
<br>
> On 9/3/13 4:13 PM, Francois Retief wrote:<br>
>> Hi all,<br>
>><br>
>> Thanks to Richard's recent improvements in the oe-core tree, I finally got my<br>
>> first MinGW build to compile through and generate a SDK tarball.<br>
>><br>
>> Next issue is that on windows GCC is unable to find the crt1.o, crti.o and<br>
>> crtbegin.o files. when compiling a small hello world app (see gist<br>
>> <<a href="https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03" target="_blank">https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03</a>><br>
>> [1] for gcc verbose output). I verified that the files are indeed in the SDK<br>
>> folders and was correctly unpacked.<br>
>><br>
>> Next, I checked the search path (-L) options and they point to the respective<br>
>> directories where the files reside.<br>
>><br>
>> Is it hard coded somewhere GCC should look for these files? Can anyone give me<br>
>> some pointers where to start looking?<br>
<br>
</div>are you passing correct --sysroot option to gcc ?<br></blockquote><div><br></div><div>I solved the compile issue on Windows by firstly adding a symbolic link to the target's sysroot directory and secondly passing a --sysroot argument to the linker.<br>
<br></div><div>Under Windows one can create a symlink with the mklink utility, So I did the following:<br><br></div><div> cd f:/oesdk/sysroots/x86_64-oesdk-mingw32/usr<br> mklink /D arm-oe-linux-gnueabi ..\..\armv5te-oe-linux-gnueabi<br>
<br></div><div>For GCC linker, I passed in <br><br> --sysroot=f:/oesdk/sysroots/armv5te-oe-linux-gnueabi<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><div class="im">
><br>
> Usually GCC can learn the location where it was executed from, and then use a relative path from that to the location where the libc and other components are located.<br>
<br>
<br>
</div>are you talking about GCC_EXEC_PREFIX ?<br></blockquote><div><br></div><div></div><div><p>I overwrite the sysroot in the MinGW gcc-cross-canadian_4.8.bbappend
recipe by changing the --with-sysroot argument in EXTRA_OECONF_PATHS
variable from</p> ${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}<br>to <br> ${exec_prefix}/../../${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}<blockquote>
</blockquote>
The ${exec_prefix} path will be replaced by GCC with its executing path to make the sysroot relative to the install path, thus eliminating the need to pass in the sysroot to the linker.<br><br></div><div>But in another email Richard mentioned that this might have unintended consequences when we start using multiple SDKs for machines.<br>
<br></div><div>Personally, I would prefer not to have to pass in a sysroot, because my MinGW SDK compiler will be used by users that knows nothing about bitbake or OpenEmbedded. My end users want to just create a new Eclipse C project and point the project to the GCC compiler and it should build out of the box. But that is another story.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5">><br>
>> Cheers,<br>
>> Francois<br>
>><br>
>> ps. I have noticed that there is a relocate_sdk.py file in the root of the SDK<br>
>> folder. What is it's purpose and can it have anything to do with the GCC search<br>
>> paths?<br>
><br>
> On linux we play with the RPATH and other components to ensure that the executables can file the libraries for execution. I don't believe that is a problem on windows as the DLLs are searched automatically.<br>
><br>
> --Mark<br>
><br>
>> [1]<br>
>> <a href="https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03" target="_blank">https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03</a><br>
>> [2] <a href="https://github.com/fgretief/meta-mingw" target="_blank">https://github.com/fgretief/meta-mingw</a><br></div></div></blockquote></div><br></div></div></div></div></div>