From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mail.openembedded.org (Postfix) with ESMTP id B32046BD75 for ; Tue, 3 Sep 2013 23:50:54 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id es20so5327906lab.10 for ; Tue, 03 Sep 2013 16:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YXm90gy+cm8x1WhLeoOgx7WiCKhpBo3FRucy39TOXqA=; b=Scwxgd19OQ+S5HXTmnqs1Iam8y748xFQnu4Sl/n1uFu0ihSR9hZ25pQbdWB//f5eMf wNqYSiKCdQVxO1va3eu8rP18kkQHDqT2fNvysU+93aAqluUqNdIZppg9eCc7rFwaRCKj zyJpBDBqmbXrMjiMOrcnL1Pju8+6qLJMS5GnhwSJCftguJH1sI3iy+6KAI2kUh0jD9mN SZ8kw08YpUgVIMiIZy3ZXEcYnjX0v/sZm5veoQOeTmdreSE7sSlli1j+pSEI/BKDBLTx A8Bn+laDzCJLlJNoIHAAjjO1O2SiMefduDoYVzwlc62hq8ibpbF8pNzoQe00ACtqW4nJ Ng+g== MIME-Version: 1.0 X-Received: by 10.152.203.233 with SMTP id kt9mr3633244lac.29.1378242802003; Tue, 03 Sep 2013 14:13:22 -0700 (PDT) Received: by 10.152.37.102 with HTTP; Tue, 3 Sep 2013 14:13:21 -0700 (PDT) Date: Tue, 3 Sep 2013 23:13:21 +0200 Message-ID: From: Francois Retief To: openembedded-core@lists.openembedded.org Subject: GCC search paths in MinGW SDK X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 23:50:55 -0000 Content-Type: multipart/alternative; boundary=001a11345984a0b5f304e5812874 --001a11345984a0b5f304e5812874 Content-Type: text/plain; charset=ISO-8859-1 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[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 --001a11345984a0b5f304e5812874 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks to Richard's rec= ent improvements in the oe-core tree, I finally got my first MinGW build to= compile through and generate a SDK tarball.

Next issue i= s that on windows GCC is unable to find the crt1.o, crti.o and crtbegin.o f= iles. 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.


<= div>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 wit= h the GCC search paths?
--001a11345984a0b5f304e5812874-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by mail.openembedded.org (Postfix) with ESMTP id 127F16BDBC for ; Wed, 4 Sep 2013 01:45:50 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id r841jq1K017363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Sep 2013 18:45:52 -0700 (PDT) Received: from Marks-MacBook-Pro.local (172.25.36.226) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.2.347.0; Tue, 3 Sep 2013 18:45:51 -0700 Message-ID: <522690CF.6030707@windriver.com> Date: Tue, 3 Sep 2013 20:45:51 -0500 From: Mark Hatle Organization: Wind River Systems User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: In-Reply-To: Subject: Re: GCC search paths in MinGW SDK X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 01:45:50 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 > > [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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (dan.rpsys.net [93.97.175.187]) by mail.openembedded.org (Postfix) with ESMTP id 6467E6BD85 for ; Wed, 4 Sep 2013 13:00:57 +0000 (UTC) Received: from localhost (dan.rpsys.net [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r84DDwgB032499; Wed, 4 Sep 2013 14:13:58 +0100 X-Virus-Scanned: Debian amavisd-new at dan.rpsys.net Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I-eYvGikm6rD; Wed, 4 Sep 2013 14:13:58 +0100 (BST) Received: from [192.168.3.10] (rpvlan0 [192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r84DDsca032491 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Sep 2013 14:13:55 +0100 Message-ID: <1378299645.1059.236.camel@ted> From: Richard Purdie To: Francois Retief Date: Wed, 04 Sep 2013 14:00:45 +0100 In-Reply-To: References: X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Cc: openembedded-core@lists.openembedded.org Subject: Re: GCC search paths in MinGW SDK X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 13:00:58 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (dan.rpsys.net [93.97.175.187]) by mail.openembedded.org (Postfix) with ESMTP id 048166BD85 for ; Wed, 4 Sep 2013 13:03:23 +0000 (UTC) Received: from localhost (dan.rpsys.net [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r84DGPLV032576; Wed, 4 Sep 2013 14:16:25 +0100 X-Virus-Scanned: Debian amavisd-new at dan.rpsys.net Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v3-sT_nPtkkk; Wed, 4 Sep 2013 14:16:25 +0100 (BST) Received: from [192.168.3.10] (rpvlan0 [192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r84DGItB032568 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Sep 2013 14:16:20 +0100 Message-ID: <1378299789.1059.238.camel@ted> From: Richard Purdie To: Mark Hatle Date: Wed, 04 Sep 2013 14:03:09 +0100 In-Reply-To: <522690CF.6030707@windriver.com> References: <522690CF.6030707@windriver.com> X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Cc: openembedded-core@lists.openembedded.org Subject: Re: GCC search paths in MinGW SDK X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 13:03:24 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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 > > > > [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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mail.openembedded.org (Postfix) with ESMTP id DF8E16BDDC for ; Wed, 4 Sep 2013 15:39:58 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id g12so623513oah.34 for ; Wed, 04 Sep 2013 08:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LcxlIp1OYaoNUZZQTSwMN8E8nbk8v+kLhMxNSTT+oKI=; b=jHSJl5NOW9pm9AVHFMsWNgkVCvBlwdByXT8FyJCc8h8+zBpcgk9YZfuPSNrf3Gr5u0 ytOG2TXraKQg4Wf+sFE9L0TyQKc4f1h9hinDWrLdMWoi7ZcUrC8RwPwunwLbNsbp00Kz LUtlvYJ+LRVm7IG5A9zAYGQnivWAkqp38T51yksyMWr91qFl6orysHxfYOmo4asywZn7 ZoGpiPJiFfafoG/88F/5INm+2fr/Sz01hJ/ImBoUly0iba0ny9Rasro5OFtS3h/DPbxB zA8qoi3Zf/NJ7H0uAHqb7p0+y5Ye0e1bzuMLfcSVVvzDwH7syqvevX48t1OzjxribBsZ lkHQ== MIME-Version: 1.0 X-Received: by 10.60.94.164 with SMTP id dd4mr1259882oeb.68.1378309200159; Wed, 04 Sep 2013 08:40:00 -0700 (PDT) Sender: otavio.salvador@gmail.com Received: by 10.182.232.166 with HTTP; Wed, 4 Sep 2013 08:40:00 -0700 (PDT) In-Reply-To: <1378299645.1059.236.camel@ted> References: <1378299645.1059.236.camel@ted> Date: Wed, 4 Sep 2013 12:40:00 -0300 X-Google-Sender-Auth: wbdRMOJnQWFhD_CTyO5xmKVczD0 Message-ID: From: Otavio Salvador To: Richard Purdie Cc: Patches and discussions about the oe-core layer Subject: Re: GCC search paths in MinGW SDK X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:39:59 -0000 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 4, 2013 at 10:00 AM, Richard Purdie 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by mail.openembedded.org (Postfix) with ESMTP id 77373615E2 for ; Fri, 13 Sep 2013 05:54:32 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id w10so800676pde.37 for ; Thu, 12 Sep 2013 22:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XLwAglfCJnv4jVTekaAIW24uCDQJkwDwjMgddPzIzHg=; b=pHm3lIy+gpZ8R6qZltIQinvBu2whHi7SxBFFTA/ZBGLr+uYkTu7AgLFQ/G99W83vc2 9ymPIYI7x+XZ4oVzbJl9DzYJWpXgalmKnSDyNilyXWVNFT/vj3vgriExWkn/vvAyMUZq Kfky1P1rvOC1bgtY7GzDRvw1o5SU8qcRcrXuP8RiV/wMl4dYK8Ee2tvonUcGN7aPTvR8 n8vTdnLvQ6SnUgq2Q0bWvTjRel6P9xO//+uArUTMk4t2DJdGkjayMo3EiUor06KIH4+H +8+uIHo3nj47kveMgcJlPDdAwOkYFqMb6wP9i84wLYxQ2RZ0Ai37Hks7KhOqd6RVPOL+ 53Dg== X-Received: by 10.68.189.98 with SMTP id gh2mr174711pbc.181.1379051674292; Thu, 12 Sep 2013 22:54:34 -0700 (PDT) Received: from [192.168.0.104] (99-57-140-209.lightspeed.sntcca.sbcglobal.net. [99.57.140.209]) by mx.google.com with ESMTPSA id ha10sm9236019pbc.23.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 22:54:33 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Khem Raj In-Reply-To: <522690CF.6030707@windriver.com> Date: Thu, 12 Sep 2013 22:54:40 -0700 Message-Id: References: <522690CF.6030707@windriver.com> To: Mark Hatle X-Mailer: Apple Mail (2.1508) Cc: openembedded-core@lists.openembedded.org Subject: Re: GCC search paths in MinGW SDK X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 05:54:33 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Sep 3, 2013, at 6:45 PM, Mark Hatle wrote: > On 9/3/13 4:13 PM, Francois Retief wrote: >> Hi all, >>=20 >> 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. >>=20 >> 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. >>=20 >> Next, I checked the search path (-L) options and they point to the = respective >> directories where the files reside. >>=20 >> 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 ? >=20 > 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 ? >=20 >> Cheers, >> Francois >>=20 >> 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? >=20 > 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. >=20 > --Mark >=20 >> [1] >> = https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-201= 3-09-03 >> [2] https://github.com/fgretief/meta-mingw >>=20 >>=20 >>=20 >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>=20 >=20 > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mail.openembedded.org (Postfix) with ESMTP id 1AD0E60CE6 for ; Fri, 13 Sep 2013 07:04:04 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id c11so1740158lbj.41 for ; Fri, 13 Sep 2013 00:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R4edaeQqVLGXFZreRjSD5TkKpZ+36eAa+QnHLikWoaA=; b=p1/vDYQyKn6+1n7HWGpvvxgUWI44uz7FHJUiEupY4twq9T6irzuKTAghIMzUYZi/OX +k9/ra8VHWeOZVhvIMbaVEvoKGVDmG1UARlMJFZCszppbOL/vGfUc4OmdFxE6h0JjBBu yQTGCjsq2tANWqWDKImX8qRGQ+fGHxWE5PmGcucMQVEjR0GU6pfZJ6BW93pQKTe9CKnm Eu/EapdyP3jG5UIIARovtmZthLorDTvpBn8+ZLyxDxyaLTybHG4fM6QwFJMKlps4VqfU NlfbrIS1C0s51zQg18X6UnvsAWDMEMAaBSB/+bfwibSLlMiUbX1lDMLuxlhrFCArOU7w KxTg== MIME-Version: 1.0 X-Received: by 10.112.60.104 with SMTP id g8mr545485lbr.32.1379055845258; Fri, 13 Sep 2013 00:04:05 -0700 (PDT) Received: by 10.152.37.102 with HTTP; Fri, 13 Sep 2013 00:04:05 -0700 (PDT) In-Reply-To: References: <522690CF.6030707@windriver.com> Date: Fri, 13 Sep 2013 09:04:05 +0200 Message-ID: From: Francois Retief To: Khem Raj Cc: openembedded-core@lists.openembedded.org Subject: Re: GCC search paths in MinGW SDK X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:04:06 -0000 Content-Type: multipart/alternative; boundary=e89a8f923ab0c83ad404e63e755a --e89a8f923ab0c83ad404e63e755a Content-Type: text/plain; charset=ISO-8859-1 Hi Khem, On 13 September 2013 07:54, Khem Raj wrote: > > On Sep 3, 2013, at 6:45 PM, 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? > > 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 > --e89a8f923ab0c83ad404e63e755a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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, cr= ti.o and
>> crtbegin.o files. when compiling a small hello world app (see gist=
>> <https://gist.github.com/f= gretief/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? =A0Can= 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 utili= ty, So I did the following:

=A0 cd f:/oesdk/sysroots/x86_= 64-oesdk-mingw32/usr
=A0 mklink /D arm-oe-linux-gnueabi ..\..\armv5te-oe= -linux-gnueabi

For GCC linker, I passed in

=A0 --sysroot=3Df:/oesdk= /sysroots/armv5te-oe-linux-gnueabi
=A0

>
> Usually GCC can learn the location where it was executed from, and the= n use a relative path from that to the location where the libc and other co= mponents are located.


are you talking about GCC_EXEC_PREFIX ?

I overwrite the sysroot in the MinGW gcc-cross-canadia= n_4.8.bbappend=20 recipe by changing the --with-sysroot argument in EXTRA_OECONF_PATHS=20 variable from

=A0 ${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${= TARGET_OS}
to
=A0 ${exec_prefix}/../../${TUNE_PKGARCH}${TARGET_VENDO= R}-${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 star= t 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 abo= ut 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.
=A0
>
>> Cheers,
>> =A0 Francois
>>
>> ps. I have noticed that there is a relocate_sdk.py file in the roo= t of the SDK
>> folder. What is it's purpose and can it have anything to do wi= th the GCC search
>> paths?
>
> On linux we play with the RPATH and other components to ensure that th= e executables can file the libraries for execution. =A0I don't believe = that is a problem on windows as the DLLs are searched automatically.
>
> --Mark
>
>> [1]
>> https://gist.github.com/fgret= ief/6429416#file-mingw-gcc-verbose-output-2013-09-03
>> [2] https://github.com/fgretief/meta-mingw

--e89a8f923ab0c83ad404e63e755a--