[OE-core] GCC search paths in MinGW SDK

[Francois Retief]

Hi Khem,


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

>
> On Sep 3, 2013, at 6:45 PM, Mark Hatle <mark.hatle at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130913/d2d4f3ef/attachment-0002.html>