Re: GCC search paths in MinGW SDK

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2013-09-03 at 20:45 -0500, Mark Hatle wrote:
> On 9/3/13 4:13 PM, Francois Retief wrote:
> > Hi all,
> >
> > Thanks to Richard's recent improvements in the oe-core tree, I finally got my
> > first MinGW build to compile through and generate a SDK tarball.
> >
> > Next issue is that on windows GCC is unable to find the crt1.o, crti.o and
> > crtbegin.o files. when compiling a small hello world app (see gist
> > <https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03>
> > [1] for gcc verbose output). I verified that the files are indeed in the SDK
> > folders and was correctly unpacked.
> >
> > Next, I checked the search path (-L) options and they point to the respective
> > directories where the files reside.
> >
> > Is it hard coded somewhere GCC should look for these files?  Can anyone give me
> > some pointers where to start looking?
> 
> 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.

Right now, the SDK works using the --sysroot option explicitly. There is
a default coded into gcc but it may or may not be correct depending on
where it was extracted to. Ultimately we should relocate that using the
tricks we use on other binaries but even then we may want to use one
compiler against multiple different sysroots.

> > ps. I have noticed that there is a relocate_sdk.py file in the root of the SDK
> > folder. What is it's purpose and can it have anything to do with the GCC search
> > paths?
> 
> 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.

FWIW we avoided the issue by statically linking the windows binaries. 

Cheers,

Richard