GCC search paths in MinGW SDK

GCC search paths in MinGW SDK

[Francois Retief]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

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?

Cheers,
  Francois

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?

[1]
https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03
[2] https://github.com/fgretief/meta-mingw

[-- Attachment #2: Type: text/html, Size: 1431 bytes --]

Re: GCC search paths in MinGW SDK

[Mark Hatle]

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.

> Cheers,
>    Francois
>
> 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.

--Mark

> [1]
> https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03
> [2] https://github.com/fgretief/meta-mingw
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: GCC search paths in MinGW SDK

[Richard Purdie]

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

Re: GCC search paths in MinGW SDK

[Khem Raj]

On Sep 3, 2013, at 6:45 PM, Mark Hatle <mark.hatle@windriver.com> 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?

are you passing correct --sysroot option to gcc ?

> 
> 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.


are you talking about GCC_EXEC_PREFIX ?
> 
>> Cheers,
>>   Francois
>> 
>> 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.
> 
> --Mark
> 
>> [1]
>> https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03
>> [2] https://github.com/fgretief/meta-mingw
>> 
>> 
>> 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: GCC search paths in MinGW SDK

[Francois Retief]

[-- Attachment #1: Type: text/plain, Size: 3410 bytes --]

Hi Khem,


On 13 September 2013 07:54, Khem Raj <raj.khem@gmail.com> wrote:

>
> On Sep 3, 2013, at 6:45 PM, Mark Hatle <mark.hatle@windriver.com> 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?
>
> are you passing correct --sysroot option to gcc ?
>

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.

Under Windows one can create a symlink with the mklink utility, So I did
the following:

  cd f:/oesdk/sysroots/x86_64-oesdk-mingw32/usr
  mklink /D arm-oe-linux-gnueabi ..\..\armv5te-oe-linux-gnueabi

For GCC linker, I passed in

  --sysroot=f:/oesdk/sysroots/armv5te-oe-linux-gnueabi


>
> >
> > 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.
>
>
> are you talking about GCC_EXEC_PREFIX ?
>

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
  ${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}
to
  ${exec_prefix}/../../${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}

 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.

But in another email Richard mentioned that this might have unintended
consequences when we start using multiple SDKs for machines.

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.


> >
> >> Cheers,
> >>   Francois
> >>
> >> 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.
> >
> > --Mark
> >
> >> [1]
> >>
> https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03
> >> [2] https://github.com/fgretief/meta-mingw
>

[-- Attachment #2: Type: text/html, Size: 4905 bytes --]

Re: GCC search paths in MinGW SDK

[Richard Purdie]

On Tue, 2013-09-03 at 23:13 +0200, Francois Retief wrote:
> 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
> [1] for gcc verbose output). I verified that the files are indeed in
> the SDK folders and was correctly unpacked. 

Make sure you specify --sysroot=xxxx where xxxx is the location of
target sysroot you want to compile against.

> 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?

It is used on Linux to help with these kinds of issues, it will be
completely useless on windows and we shouldn't ship it there.

I've shared the result of my tweaks as
http://git.yoctoproject.org/cgit.cgi/meta-mingw/ btw. I flattened the
history as I had a ton of now meaningless commits and tests so it made
sense for a clean start IMO.

Cheers,

Richard

Re: GCC search paths in MinGW SDK

[Otavio Salvador]

On Wed, Sep 4, 2013 at 10:00 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I've shared the result of my tweaks as
> http://git.yoctoproject.org/cgit.cgi/meta-mingw/ btw. I flattened the
> history as I had a ton of now meaningless commits and tests so it made
> sense for a clean start IMO.

Richard, I think it is better if we use Francois repository and don't
make it under git.yoctoproject.org for now. It will confuse people and
potentially people can base work on this, instead of Francois one.
Once Francois is happy with this, it can be moved to
git.yoctoproject.org and turn github one into a mirror of it.

My 2c.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750