From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx1.pokylinux.org (Postfix) with ESMTP id 1626A4C8085F for ; Mon, 17 Jan 2011 13:46:19 -0600 (CST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 17 Jan 2011 11:46:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.60,334,1291622400"; d="p7s'?scan'208,217";a="697700184" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga001.jf.intel.com with ESMTP; 17 Jan 2011 11:46:18 -0800 Received: from orsmsx504.amr.corp.intel.com ([10.22.226.207]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Mon, 17 Jan 2011 11:46:18 -0800 From: "Zhang, Jessica" To: "Purdie, Richard" Date: Mon, 17 Jan 2011 11:46:17 -0800 Thread-Topic: sysroot question Thread-Index: Acu2fzSEXLkuKhFMRACbXss+jKuQNg== Message-ID: <9AFCD584B0B67B48AE8D8585BE30BA9504E1482C@orsmsx504.amr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "poky@yoctoproject.org" Subject: sysroot question X-BeenThere: poky@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Poky build system developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:46:19 -0000 X-Groupsio-MsgNum: 2387 Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01CBB63C.26722960" ------=_NextPart_000_0010_01CBB63C.26722960 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01CBB63C.26722960" ------=_NextPart_001_0011_01CBB63C.26722960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Richard, While testing the sysroot setup, I noticed there're some variation between the sysroot that built by meta-toolchain and qemu-image-sdk. For example, limits.h, if I search for it under the meta-toolchain sysroot, I got the following: jzhang@jzhang-desktop:/opt/poky/0.9+snapshot$ find . -name limits.h ./sysroots/i586-poky-linux/usr/include/limits.h ./sysroots/i586-poky-linux/usr/include/linux/limits.h ./sysroots/i586-poky-linux/usr/include/c++/tr1/limits.h ./sysroots/i686-pokysdk-linux/usr/lib/i586-poky-linux/gcc/i586-poky-linux/4. 5.1/include-fixed/limits.h ./sysroots/i686-pokysdk-linux/usr/include/limits.h and the sysroot extract from qemu-image-sdk, gave me this: jzhang@jzhang-desktop:~/qemu-x86$ find . -name limits.h ./usr/lib/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h ./usr/include/c++/tr1/limits.h ./usr/include/limits.h This caused problem in test programs of suduku which looking for . The question is where should I look that cause the sysroot content variation? Thanks, Jessica ------=_NextPart_001_0011_01CBB63C.26722960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 Richard,

While = testing the=20 sysroot setup, I noticed there're some variation between the sysroot = that built=20 by meta-toolchain and qemu-image-sdk. For example, limits.h, if I = search=20 for it under the meta-toolchain sysroot, I got the=20 following:

jzhang@jzha= ng-desktop:/opt/poky/0.9+snapshot$=20 find . -name=20 limits.h
./sysroots/i586-poky-linux/usr/include/limits.h
./sysroots= /i586-poky-linux/usr/include/linux/limits.h
./sysroots/i586-poky-linux= /usr/include/c++/tr1/limits.h
./sysroots/i686-pokysdk-linux/usr/lib/i5= 86-poky-linux/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h
./sysro= ots/i686-pokysdk-linux/usr/include/limits.h

and = the sysroot=20 extract from qemu-image-sdk, gave me this:

jzhang@jzhang-desktop:~= /qemu-x86$=20 find . -name=20 limits.h
./usr/lib/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h./usr/include/c++/tr1/limits.h
./usr/include/limits.h

This = caused problem=20 in test programs of suduku which looking for = <linux/limits.h>. The=20 question is where should I look that cause the sysroot content=20 variation?

Thanks,

Jessica

------=_NextPart_001_0011_01CBB63C.26722960-- ------=_NextPart_000_0010_01CBB63C.26722960 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIdiDCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFYzCCBEugAwIBAgIKYSyUiQAA AAAABTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wNjAzMjIy MjIyNDJaFw0xMjAzMjIyMjMyNDJaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKvXqH/ah10uJc7YzQUh+XEDNqS6IsXOyqCtizr9 x6F+v6iRAbvddRRJRWixfV78qarSN9WMymJ90M8c9/Dfr1yzFuq95RgCAF3vdve3wKi7kJv6lkMJ wyyB+uIYcWtljYx2LDqbb9S6Z6He3q8W/aGKvu23I9ksNx+cmZcDNZwGdXVIEHpEMyA4bp0RvYtf p8BsGAyn6YuK63HugeyYdeFL+4+Wz2tGUqw9OWhob6oV1oDH3zboLhHJiQ2oIj3jAJ3/LrIkzcWP 2R20UIliDAPAAl6MNWJPdsNK5EEeuxEuUSpdFsMj5rBmPHH4U8i8rUmi6GEOcX5rwAw64AzS3gEC AwEAAaOCAjUwggIxMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAlpgTN7BnOPI0wKA9/3FoER ghMFMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi AEMAQTAfBgNVHSMEGDAWgBQaxgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGs oIGphk5odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFs JTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNy bDCB4wYIKwYBBQUHAQEEgdYwgdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3Jl cG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUy MENBLmNydDBsBggrBgEFBQcwAoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCuNCnecJ+vDpXzsHOzMEyz4KgTNDbJROHag8H/ZVga7soc oJyC+HKqDfQgxifVorbTbSajCBEAxqg6bbNWBJ6qKOFHneBrXkENf5WdD50eCTCFWRV3EIsHEOQ1 kP0eNYV5Ed4hp9y6wASV6z2z86O4+qouLJiow4AIhoCKD8rEyD7ODgTvjvLCKpsVyPlG1jOVSsOS IF2VUmueAmK3RFU4np83zerK/j0G37owhniEDT6ZhwkUd0XL45nt1m7yApMEbnXUTHNaXnE+P98k k3nDXdW25sB+5xWcYR3GpgMdQiZgP/f0KZ+yZKNE7gcp3I/O4pXqUNWIsLSYTi3soAR2MIIFYzCC BEugAwIBAgIKYSyl/gAAAAAABjANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UE ChMRSW50ZWwgQ29ycG9yYXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGlj eSBDQTAeFw0wNjAzMjIyMjIyNDdaFw0xMjAzMjIyMjMyNDdaMFYxCzAJBgNVBAYTAlVTMRowGAYD VQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNz dWluZyBDQSAzQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMDoHJYUGvcdR4k0Qv8/ RrwNX4+vEe5PN2LnGn4xfIWwdUbk5+zvrRy1HjoKdG/AShZfxAuFoVyNIah5GJLpiS/vGbsDYKK+ EZcIcmtPfvbB9Yg09EnQ0OpsZ2ORRd5lYUfMUU+zkpgL96vKFdkiG+eeHEwnSS3VikGVrF7UDdKf vxZwRwQCx6rEHAFPCjBDVfGYZuYT1EDhSDvzEiU7KzBsxrdBCFU4RYL7kh+do+vyMDlBzpw3WKvM Vbf3s5lxYiY7AjEhU8OSyZEQlgtK8PNyifHjmyrSaeJrPshM3PuLFG4d3gm1UJEiGNzxcHGb6YLP 29IQAwY5mAk8j+UOVcsCAwEAAaOCAjUwggIxMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFG/D cREooZ0ZV/VnV8/ZKSaI1aWiMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEE AYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQaxgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYD VR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9J bnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZp Y2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUy MFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYwgdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93 d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBC YXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcwAoZgaHR0cDovL2NlcnRpZmljYXRlcy5p bnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2lj JTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBAiWWHL6T21QXFZDyaUIye0jh7 f40GXqi75Ro5JbpROtlZBqyRq6oPMAG6Igxd5Bd9TMtNkOvguknFnK1y17UdMhLOl+FuInE+FAWk 803aRW27OsX+ot0KmPioKnZ3L1K5qcQS3tp6or7AaZzd0w0qFitm4UfP9nnTXQtY9XM5QJ07IKFD E3tlOlamKhjbiJV3FKigCVesPZSx9h2G7Ve4irEfz915Vks26AJHGZagEHNxM9exkgem4ENsG+t0 vYqn9x7YsqJ6fmbOSyrzjzb3CYeEfyE5SL+f3Vx9uMsQDyb8LVCDBXQtxLEHnFEBPrRSSF9kPmyj avx4UqFdPEyCMIIGAzCCBOugAwIBAgIKGmwusAAAAAApdjANBgkqhkiG9w0BAQUFADBWMQswCQYD VQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVy bmFsIEJhc2ljIElzc3VpbmcgQ0EgM0IwHhcNMDgwNDE0MjMxNDQ4WhcNMTEwNDE0MjMxNDQ4WjBB MRcwFQYDVQQDEw5aaGFuZywgSmVzc2ljYTEmMCQGCSqGSIb3DQEJARYXamVzc2ljYS56aGFuZ0Bp bnRlbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQbirxoX/8OWYyzy4UnZ7N xXoADLZqxxH1q4lMF2zuAHjyDnNj/4ReRzB6AIDEg1BQWS4z5jC6oApos3HvFEsGbS3pYCWSo5Vb jtY5HWOBRPJ2rQ8wzITqcEEBWooYCj5LJeAjPuOZoZPVrKPI1khbOYzaJUwQpICfaErHZyM4p2mV AYXcUa/N0zKGnZmNaO6Dff96g41C9jEyfOFEtYOpLdQoXhD1i8tW17WxbHMuiXx3PR3GUdBADrRf I3wzqn4rh0y0D4l9mBfgTybVN3UR35ZFGSRsuldyJeeKcCSgghJi3K4ZTxzMfQ6+OKBu6SBeNKWk e2Q4f8CIf0+8ZpwfAgMBAAGjggLmMIIC4jALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFPIpOYEzCqH+ 037yR8d0Rarz7r7mMDwGCSsGAQQBgjcVBwQvMC0GJSsGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OC kcAJZ4HevTmV8EMCAWQCAQYwHwYDVR0jBBgwFoAUb8NxESihnRlX9WdXz9kpJojVpaIwgckGA1Ud HwSBwTCBvjCBu6CBuKCBtYZUaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50 ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0IuY3Jshl1odHRwOi8vY2Vy dGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFz aWMlMjBJc3N1aW5nJTIwQ0ElMjAzQi5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAC hl1odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4 dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQi5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6 Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIw RXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNCLmNydDAfBgNVHSUEGDAWBggrBgEF BQcDBAYKKwYBBAGCNwoDDDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcK AwwwSwYDVR0RBEQwQqAnBgorBgEEAYI3FAIDoBkMF2plc3NpY2EuemhhbmdAaW50ZWwuY29tgRdq ZXNzaWNhLnpoYW5nQGludGVsLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEANFSBbauSm1ktwUQI6fGq 9XhTSUsty5/CHOrOwFe4K7LX0clVirXUYakIZXXG86lD1piRrjt23MhKRekYNIv0mfJklEF7yV5M VVqwDK1Uz6bsiw/SQnqfBuFrd70W4cua3bU1uu3dAhZBh482BtBZYFockuHd3YBFT7xmykOaAMLP CttrNSijP7HsbetGG2GLLc3CWauSXXr2ELseXkw3KkUKBPMw+DFAJdsRyBe0L+OwlDplr8POBXXb uuQK7Wo84mX7gMT0uSq/Luex/BD1xn2brKVs9t4FvL8ifxv4LuWRzv45EgPN4T12I202GBQ8iJtZ DkT3+9QPiQ35Hmuy6zCCBkowggUyoAMCAQICCnmKHVEAAAAAHyswDQYJKoZIhvcNAQEFBQAwVjEL MAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBF eHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBMB4XDTA4MDQxNDIzMTM1MVoXDTExMDQxNDIzMTM1 MVowQTEXMBUGA1UEAxMOWmhhbmcsIEplc3NpY2ExJjAkBgkqhkiG9w0BCQEWF2plc3NpY2Euemhh bmdAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Lgwg9E/0F9weWx5 ZCk0oiuerOIqOFTXcithjh7zRhiq8v/z9sXR/yWXUA7JK5E5JLPRNl0nQJFv/FLTaq9/9PchiI/N 4v7L/ERXTzdMNvwOEqNOy8SOmmOOjF8N1vtrIv+WdBYiqBvtfQ9xGXadxckgrBOSTtTrw4iShbnG mVrw6mYYIOdPIKhq3QFmxHs93R8IrmIjvMbf31JhiAp7KJ/mc+bckmYW/9fNNEQkMbuF3B6iWsTk 8c+D8oWmxuw+m6svwEMKck8yr3ldF6sZ6NCKXJChwDmjZMHBBSV6IUUycyl6SJ33j3r9Beki5bvG mhZnfGBLWODaLv4PDbG7BwIDAQABo4IDLTCCAykwCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3 MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAd BgNVHQ4EFgQUKEdHKlCw71rRzz5gJWoRJwoviW0wPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUI hsOMdYSZ5VGD/YEohY6fU4KRwAlnhLnZQYeE/04CAWQCAQkwHwYDVR0jBBgwFoAUCWmBM3sGc48j TAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCBtYZUaHR0cDovL3d3dy5pbnRlbC5jb20v cmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIw M0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRl bCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQS5jcmwwge8GCCsGAQUFBwEB BIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRp ZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQS5jcnQw cgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2Vy dGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNBLmNy dDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDBDApBgkrBgEEAYI3FQoEHDAaMAoGCCsG AQUFBwMEMAwGCisGAQQBgjcKAwQwSwYDVR0RBEQwQqAnBgorBgEEAYI3FAIDoBkMF2plc3NpY2Eu emhhbmdAaW50ZWwuY29tgRdqZXNzaWNhLnpoYW5nQGludGVsLmNvbTANBgkqhkiG9w0BAQUFAAOC AQEAlkSHAnj2YSCjtyOIJJtoNia1mv4qLpp3rxqxeZzEG9Bk4k4hGHkozj1p+mi368ieYl/fTPtK IIBDCwod9o12adTGGW7wyUHjZfalumhsFoKTXbUU/CC7lpooUKuDxCjaIjsc4rdDxP1MEAUX43IG kLRqq9elDWluC0WjR+q+cAqKMJxLmAKhKz7JDTNrbfWwuoETGdCMkLUK464/FSvfDKoV+Ypkoq1x YiTi71VhwWenYKPnyKbLgiULEgdfwQscMzJQ9rmq1iyfoXuXPSkCA6nfZKoSkBOVJQXjW/+B2wxe YmaO9Qc5P3CJvsmgmgX5mK2wyKEw0JCwTHE3w7FkFjGCA0EwggM9AgEBMGQwVjELMAkGA1UEBhMC VVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBC YXNpYyBJc3N1aW5nIENBIDNCAgoabC6wAAAAACl2MAkGBSsOAwIaBQCgggGyMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExNzE5NDYxNlowIwYJKoZIhvcNAQkE MRYEFLEGVAp0aZ1Aikhezefe28TxvwLzMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMHMGCSsGAQQBgjcQBDFmMGQwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5n IENBIDNBAgp5ih1RAAAAAB8rMHUGCyqGSIb3DQEJEAILMWagZDBWMQswCQYDVQQGEwJVUzEaMBgG A1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElz c3VpbmcgQ0EgM0ECCnmKHVEAAAAAHyswDQYJKoZIhvcNAQEBBQAEggEAptSWwW+6JQCIgiQ/WxPH DN5UL5pez5bK71yafdfr5oGraBaOhtkELNAiyKZX/fb2LrX/27oHGv6gK0cAeMOi1V7Mk4h5C3h+ xztkzVz8AB9Fmeafx+rUgJqLq9JdVAJi/ee3jIhNfEg34wzb/z/11NOAcn/54qKrq0k47A3iFGU2 x1pPsD3p6Iyuyrb7hJNNV2L4zwtmtUuUgb066XbCu/a1CPjwiaQutWFO0Xp7qxHKh5yvjEvMmBzL VRZNY/h2/E5VbNuSPD7AIqW9lg4RbpsY17YNEjnkfEToimXFlOavkKMJjwPxY92qom14ZWSLfB27 slLtY5XeeDDbRrBoVQAAAAAAAA== ------=_NextPart_000_0010_01CBB63C.26722960-- 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 mx1.pokylinux.org (Postfix) with ESMTP id 33DFC4C80039 for ; Mon, 17 Jan 2011 14:01:53 -0600 (CST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id p0HK1qd2029499 for ; Mon, 17 Jan 2011 12:01:52 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jan 2011 12:01:52 -0800 Received: from Macintosh-5.local ([172.25.36.226]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jan 2011 12:01:52 -0800 Message-ID: <4D34A02F.7080507@windriver.com> Date: Mon, 17 Jan 2011 14:01:51 -0600 From: Mark Hatle Organization: Wind River Systems User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: poky@yoctoproject.org References: <9AFCD584B0B67B48AE8D8585BE30BA9504E1482C@orsmsx504.amr.corp.intel.com> In-Reply-To: <9AFCD584B0B67B48AE8D8585BE30BA9504E1482C@orsmsx504.amr.corp.intel.com> X-OriginalArrivalTime: 17 Jan 2011 20:01:52.0357 (UTC) FILETIME=[62213150:01CBB681] Subject: Re: sysroot question X-BeenThere: poky@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Poky build system developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:01:53 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/17/11 1:46 PM, Zhang, Jessica wrote: > Hi Richard, > > While testing the sysroot setup, I noticed there're some variation between the > sysroot that built by meta-toolchain and qemu-image-sdk. For example, limits.h, > if I search for it under the meta-toolchain sysroot, I got the following: > > jzhang@jzhang-desktop:/opt/poky/0.9+snapshot$ > find . -name limits.h > ./sysroots/i586-poky-linux/usr/include/limits.h > ./sysroots/i586-poky-linux/usr/include/linux/limits.h > ./sysroots/i586-poky-linux/usr/include/c++/tr1/limits.h > ./sysroots/i686-pokysdk-linux/usr/lib/i586-poky-linux/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h > ./sysroots/i686-pokysdk-linux/usr/include/limits.h > > and the sysroot extract from qemu-image-sdk, gave me this: > > jzhang@jzhang-desktop:~/qemu-x86$ > find . -name limits.h > ./usr/lib/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h > ./usr/include/c++/tr1/limits.h > ./usr/include/limits.h > This caused problem in test programs of suduku which looking for > . The question is where should I look that cause the sysroot > content variation? It is almost always a bug in an application to include . The ONLY valid exceptions are when they need an ioctl, syscall or similar definition that is not available via the standard set of includes. I highly doubt suduku fits this, so it's a bug in the test program. (but yes, I also suspect that /usr/include/linux/... will be needed in the SDK, so thats ALSO likely a defect..) --Mark > Thanks, > Jessica > > > > _______________________________________________ > poky mailing list > poky@yoctoproject.org > https://lists.yoctoproject.org/listinfo/poky From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 4C002E00924; Wed, 8 Feb 2017 02:42:37 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail.analogue-micro.com (mail.analogue-micro.com [217.144.149.242]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 62A67E007AD for ; Wed, 8 Feb 2017 02:42:33 -0800 (PST) Received: by mail.analogue-micro.com (Postfix, from userid 999) id A006A68A019; Wed, 8 Feb 2017 10:42:31 +0000 (GMT) Received: from zeus.mlbassoc.com (unknown [10.8.0.2]) by mail.analogue-micro.com (Postfix) with ESMTP id 3BBF868A019; Wed, 8 Feb 2017 10:42:31 +0000 (GMT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by zeus.mlbassoc.com (Postfix) with ESMTP id E942D67401F4; Wed, 8 Feb 2017 11:42:30 +0100 (CET) To: "yocto@yoctoproject.org" From: Gary Thomas Message-ID: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> Date: Wed, 8 Feb 2017 11:42:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Subject: sysroot question X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:42:37 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I had a recipe that used to work and now fails after the change to the split sysroots. I'm building an out-of-tree kernel module and patterned my recipe after the meta-skeleton example. My recipe has this setup: inherit module-base kernel-module-split do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ KERNEL_VERSION=${KERNEL_VERSION} \ CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ AR="${KERNEL_AR}" \ O=${STAGING_KERNEL_BUILDDIR} \ install } The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be found. I know it's available, just not sure what needs to change to be able to find it. $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc" tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi-gcc tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc Any suggestions on how I fix this? Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 4FA60E009A5; Wed, 8 Feb 2017 03:12:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail.analogue-micro.com (mail.analogue-micro.com [217.144.149.242]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 0C701E007AD for ; Wed, 8 Feb 2017 03:12:27 -0800 (PST) Received: by mail.analogue-micro.com (Postfix, from userid 999) id 46AAA68A019; Wed, 8 Feb 2017 11:12:26 +0000 (GMT) Received: from zeus.mlbassoc.com (unknown [10.8.0.2]) by mail.analogue-micro.com (Postfix) with ESMTP id CF0C968A019; Wed, 8 Feb 2017 11:12:25 +0000 (GMT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by zeus.mlbassoc.com (Postfix) with ESMTP id 84BBE67400D4; Wed, 8 Feb 2017 12:12:25 +0100 (CET) To: yocto@yoctoproject.org References: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> From: Gary Thomas Message-ID: <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> Date: Wed, 8 Feb 2017 12:12:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> Subject: Re: sysroot question X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 11:12:31 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2017-02-08 11:42, Gary Thomas wrote: > I had a recipe that used to work and now fails after the change > to the split sysroots. I'm building an out-of-tree kernel module > and patterned my recipe after the meta-skeleton example. My recipe > has this setup: > > inherit module-base kernel-module-split > > do_compile() { > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ > KERNEL_VERSION=${KERNEL_VERSION} \ > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > AR="${KERNEL_AR}" \ > O=${STAGING_KERNEL_BUILDDIR} \ > install > } > > The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be > found. I know it's available, just not sure what needs to change to be > able to find it. > > $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc" > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi-gcc > > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc > > > > Any suggestions on how I fix this? > > Thanks > It looks like the failure is actually happening in a class method (make_scripts) My recipe also contains this addtask make_scripts after do_patch before do_compile which doesn't seem to be setting the ${PATH} correctly anymore. Any ideas what might be missing? Note: just moving the call to do_make_scripts to the top of do_compile instead of running it as a separate task fixes the problem. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id BC32CE009AA; Wed, 8 Feb 2017 05:57:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, * medium trust * [134.134.136.100 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 65283E007AD for ; Wed, 8 Feb 2017 05:57:44 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP; 08 Feb 2017 05:57:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,346,1477983600"; d="scan'208";a="1123758179" Received: from jlock-mobl1.ger.corp.intel.com ([10.252.16.172]) by fmsmga002.fm.intel.com with ESMTP; 08 Feb 2017 05:57:42 -0800 Message-ID: <1486562261.3754.6.camel@linux.intel.com> From: Joshua Lock To: Gary Thomas , yocto@yoctoproject.org Date: Wed, 08 Feb 2017 13:57:41 +0000 In-Reply-To: <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> References: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> X-Mailer: Evolution 3.22.4 (3.22.4-2.fc25) Mime-Version: 1.0 Subject: Re: sysroot question X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:57:46 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2017-02-08 at 12:12 +0100, Gary Thomas wrote: > On 2017-02-08 11:42, Gary Thomas wrote: > > I had a recipe that used to work and now fails after the change > > to the split sysroots. I'm building an out-of-tree kernel module > > and patterned my recipe after the meta-skeleton example. My recipe > > has this setup: > > > > inherit module-base kernel-module-split > > > > do_compile() { > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > > oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ > > KERNEL_VERSION=${KERNEL_VERSION} \ > > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > > AR="${KERNEL_AR}" \ > > O=${STAGING_KERNEL_BUILDDIR} \ > > install > > } > > > > The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no > > longer be > > found. I know it's available, just not sure what needs to change > > to be > > able to find it. > > > > $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name > > "arm*gcc" > > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2- > > r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux- > > gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi- > > gcc > > > > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2- > > r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd- > > linux-gnueabi-gcc > > > > > > > > Any suggestions on how I fix this? > > > > Thanks > > > > It looks like the failure is actually happening in a class method > (make_scripts) > My recipe also contains this > addtask make_scripts after do_patch before do_compile > which doesn't seem to be setting the ${PATH} correctly anymore. > > Any ideas what might be missing? Does make_scripts set cwd using the dirs varflag? http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-use r-manual.html#variable-flags i.e. meta/classes/base.bbclass:do_compile[dirs] = "${B}" Joshua From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id CA9E1E0093F; Wed, 8 Feb 2017 11:37:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high * trust * [192.55.52.88 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 98212E006C6 for ; Wed, 8 Feb 2017 11:36:59 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 08 Feb 2017 11:36:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,348,1484035200"; d="scan'208";a="1092453262" Received: from choutinx-mobl1.gar.corp.intel.com (HELO peggleto-mobl.ger.corp.intel.com) ([10.255.134.120]) by orsmga001.jf.intel.com with ESMTP; 08 Feb 2017 11:36:56 -0800 From: Paul Eggleton To: Gary Thomas Date: Thu, 09 Feb 2017 08:36:54 +1300 Message-ID: <15650683.oLyvIqKQ2l@peggleto-mobl.ger.corp.intel.com> Organization: Intel Corporation User-Agent: KMail/5.3.3 (Linux/4.9.7-201.fc25.x86_64; KDE/5.29.0; x86_64; ; ) In-Reply-To: <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> References: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> MIME-Version: 1.0 Cc: yocto@yoctoproject.org Subject: Re: sysroot question X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:37:02 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi Gary, On Wednesday, 8 February 2017 12:12:25 PM NZDT Gary Thomas wrote: > On 2017-02-08 11:42, Gary Thomas wrote: > > I had a recipe that used to work and now fails after the change > > to the split sysroots. I'm building an out-of-tree kernel module > > and patterned my recipe after the meta-skeleton example. My recipe > > has this setup: > > > > inherit module-base kernel-module-split > > > > do_compile() { > > > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS > > oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ > > > > KERNEL_VERSION=${KERNEL_VERSION} \ > > CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ > > AR="${KERNEL_AR}" \ > > > > O=${STAGING_KERNEL_BUILDDIR} \ > > > > install > > > > } > > > > The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be > > found. I know it's available, just not sure what needs to change to be > > able to find it. > > > > $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc" > > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr > > oot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi > > /5.4.0/arm-amltd-linux-gnueabi-gcc > > > > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr > > oot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc > > It looks like the failure is actually happening in a class method > (make_scripts) My recipe also contains this > addtask make_scripts after do_patch before do_compile > which doesn't seem to be setting the ${PATH} correctly anymore. > > Any ideas what might be missing? > > Note: just moving the call to do_make_scripts to the top of do_compile > instead of running it as a separate task fixes the problem. I think the problem is that the task that prepares the sysroot (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass uses this: addtask make_scripts after do_prepare_recipe_sysroot before do_compile BTW you say you patterned your recipe after the skeleton example, except hello-mod at least currently inherits module rather than module-base + kernel- module-split - is there a compelling reason not to inherit module? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 900FCE009CD; Wed, 8 Feb 2017 20:24:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail.analogue-micro.com (mail.analogue-micro.com [217.144.149.242]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 1795EE00939 for ; Wed, 8 Feb 2017 20:23:58 -0800 (PST) Received: by mail.analogue-micro.com (Postfix, from userid 999) id C2CEA68A01C; Thu, 9 Feb 2017 04:23:56 +0000 (GMT) Received: from zeus.mlbassoc.com (unknown [10.8.0.2]) by mail.analogue-micro.com (Postfix) with ESMTP id 4A0D768A019; Thu, 9 Feb 2017 04:23:56 +0000 (GMT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by zeus.mlbassoc.com (Postfix) with ESMTP id B3D4867402A6; Thu, 9 Feb 2017 05:23:55 +0100 (CET) From: Gary Thomas To: yocto@yoctoproject.org References: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> <15650683.oLyvIqKQ2l@peggleto-mobl.ger.corp.intel.com> Message-ID: <31b81d5d-a30a-3a1a-bdcd-9a91b03d7b85@mlbassoc.com> Date: Thu, 9 Feb 2017 05:23:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <15650683.oLyvIqKQ2l@peggleto-mobl.ger.corp.intel.com> Subject: Re: sysroot question X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 04:24:02 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2017-02-08 20:36, Paul Eggleton wrote: > Hi Gary, > > On Wednesday, 8 February 2017 12:12:25 PM NZDT Gary Thomas wrote: >> On 2017-02-08 11:42, Gary Thomas wrote: >>> I had a recipe that used to work and now fails after the change >>> to the split sysroots. I'm building an out-of-tree kernel module >>> and patterned my recipe after the meta-skeleton example. My recipe >>> has this setup: >>> >>> inherit module-base kernel-module-split >>> >>> do_compile() { >>> >>> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS >>> oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \ >>> >>> KERNEL_VERSION=${KERNEL_VERSION} \ >>> CC="${KERNEL_CC}" LD="${KERNEL_LD}" \ >>> AR="${KERNEL_AR}" \ >>> >>> O=${STAGING_KERNEL_BUILDDIR} \ >>> >>> install >>> >>> } >>> >>> The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be >>> found. I know it's available, just not sure what needs to change to be >>> able to find it. >>> >>> $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc" >>> tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr >>> oot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi >>> /5.4.0/arm-amltd-linux-gnueabi-gcc >>> >>> tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr >>> oot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc >> >> It looks like the failure is actually happening in a class method >> (make_scripts) My recipe also contains this >> addtask make_scripts after do_patch before do_compile >> which doesn't seem to be setting the ${PATH} correctly anymore. >> >> Any ideas what might be missing? >> >> Note: just moving the call to do_make_scripts to the top of do_compile >> instead of running it as a separate task fixes the problem. > > I think the problem is that the task that prepares the sysroot > (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass > uses this: > > addtask make_scripts after do_prepare_recipe_sysroot before do_compile > > BTW you say you patterned your recipe after the skeleton example, except > hello-mod at least currently inherits module rather than module-base + kernel- > module-split - is there a compelling reason not to inherit module? I may have been mistaken about the original source - it looks like I used a similar module strategy from meta-freescale. I did [just now] try using "inherit module" and the build dies a horrible death with this error | make: *** No rule to make target 'modules_install'. Stop. I changed my [task] dependencies to match what you've quoted and everything works as before. !Thanks! -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 35C2DE009DA; Wed, 8 Feb 2017 23:49:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-HAM-Report: * 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source * [209.85.215.42 listed in dnsbl.sorbs.net] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [209.85.215.42 listed in list.dnswl.org] Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id BD3C9E00939 for ; Wed, 8 Feb 2017 23:49:11 -0800 (PST) Received: by mail-lf0-f42.google.com with SMTP id z134so96365208lff.3 for ; Wed, 08 Feb 2017 23:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chargestorm-se.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:organization :user-agent; bh=KeCP0/9Fiogjo7EO5RJkWIoIPk+oLahM1JRbBHjELF4=; b=jJ33JjMfzSziwvm7yIAPKVOV53vsFC918NL0xBPXWqKGOBFGSXIdl7NqTOB6Qr0fq3 u2U5ZVEoact44UXJGDewVTtysrxFH6Cy31bgRX5F6Tn0vMyhOKsz3acIl2Nq9Bv2Ns2m PoKNVWlK6Vj02Xuh1VVVMBR/eLMP+JhlBQ99O1iyKFocYTj3mhNXWetixCspIavxbDgr SnhKJic5lNCv66Ds2xl1GWDbHkDFeKsUH8aL57H4z0LidJLhEziQn/uJjIOxTHM+CjY+ 2rKXaBgDgWHm4dHetM83LqmE2SyYAOEc3ZxxLqZHegKCevYp9xkfrgug2+iVWSZaXwN+ mySg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to :organization:user-agent; bh=KeCP0/9Fiogjo7EO5RJkWIoIPk+oLahM1JRbBHjELF4=; b=sE6Q4EcrafowzvJSD0v9AZDjPQIgoZpjI6HxD/ll5P7m0gxoaa18J+DPbc9y71B4DO JeFevDTxkPMd+qQqfUjs0TtveKs+Wf2I+YnIW+maGx1Hzs30q+G+MG7U4UMGS6X7iUOu PLO4XMP5oWC11L/6UgfIQy1c1tWWrcfeRcbTDPzvmrm/jkwizTceE4+OhNVAFGPcObwL ztEMSjI3QyD8PzYTkDbHRHudtehnkAM/SrkF4B3ANME6GDhbeLs+haPIMbKpnYCjshf3 HqyNugF3wu0VscI3yNdrljcmw5N3+Z1rSxysz1BHIzgnZoHdwS9HKIVxA98LYSUdaDvi a0Yw== X-Gm-Message-State: AMke39kj73bKtuVYCiBLSOi0ofTQFlLHf3LZ4UZIrKCOkeH3yoAVm8d1XyLy+YIu+gV+EQ== X-Received: by 10.46.77.9 with SMTP id a9mr644149ljb.25.1486626549785; Wed, 08 Feb 2017 23:49:09 -0800 (PST) Received: from ad.chargestorm.se (h83-209-191-235.cust.se.alltele.net. [83.209.191.235]) by smtp.gmail.com with ESMTPSA id a71sm3211072lfe.36.2017.02.08.23.49.08 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Feb 2017 23:49:08 -0800 (PST) Date: Thu, 9 Feb 2017 08:49:07 +0100 From: Anders Darander To: yocto@yoctoproject.org Message-ID: <20170209074907.u2ghryme4xzxopi7@ad.chargestorm.se> Mail-Followup-To: yocto@yoctoproject.org References: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> <15650683.oLyvIqKQ2l@peggleto-mobl.ger.corp.intel.com> <31b81d5d-a30a-3a1a-bdcd-9a91b03d7b85@mlbassoc.com> MIME-Version: 1.0 In-Reply-To: <31b81d5d-a30a-3a1a-bdcd-9a91b03d7b85@mlbassoc.com> X-Accept-Language: sv, en, de X-GPG-Fingerprint: 5AF0 B2E9 78FE 9D75 D110 6F8F 3E31 84D7 920E 938C X-GPG-Key-Id: 0x920E938C X-GPG-Keyserver: hkp://keys.gnupg.net Organization: ChargeStorm AB User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: sysroot question X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 07:49:15 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Gary Thomas [170209 05:25]: > On 2017-02-08 20:36, Paul Eggleton wrote: > > I think the problem is that the task that prepares the sysroot > > (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass > > uses this: > > addtask make_scripts after do_prepare_recipe_sysroot before do_compile > > BTW you say you patterned your recipe after the skeleton example, except > > hello-mod at least currently inherits module rather than module-base + kernel- > > module-split - is there a compelling reason not to inherit module? > I may have been mistaken about the original source - it looks like I > used a similar module strategy from meta-freescale. I did [just now] > try using "inherit module" and the build dies a horrible death with > this error > | make: *** No rule to make target 'modules_install'. Stop. Well, that is simple to solve. module.bbclasses sets MODULES_INSTALL_TARGET ?= "modules_install" just override that with your own install target. (Or fix the module's Makefile). The last option is to simply override do_install in your recipe. > I changed my [task] dependencies to match what you've quoted and everything > works as before. !Thanks! I'd still recommend doing as little as possible in each recipe, and leverage the standard modules. Cheers, Anders -- Anders Darander, Senior System Architect ChargeStorm AB / eStorm AB From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 24872E009F6; Thu, 9 Feb 2017 00:05:08 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail.analogue-micro.com (mail.analogue-micro.com [217.144.149.242]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id E1D31E009CD for ; Thu, 9 Feb 2017 00:05:04 -0800 (PST) Received: by mail.analogue-micro.com (Postfix, from userid 999) id CB87868A019; Thu, 9 Feb 2017 08:05:03 +0000 (GMT) Received: from zeus.mlbassoc.com (unknown [10.8.0.2]) by mail.analogue-micro.com (Postfix) with ESMTP id 4399868A019; Thu, 9 Feb 2017 08:05:01 +0000 (GMT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by zeus.mlbassoc.com (Postfix) with ESMTP id A006B67400D4; Thu, 9 Feb 2017 09:05:00 +0100 (CET) To: yocto@yoctoproject.org References: <39e27fc1-7ad6-9411-5cd1-96628e962f75@mlbassoc.com> <89ae4442-5ec2-7d25-1245-dc4e9af683b9@mlbassoc.com> <15650683.oLyvIqKQ2l@peggleto-mobl.ger.corp.intel.com> <31b81d5d-a30a-3a1a-bdcd-9a91b03d7b85@mlbassoc.com> <20170209074907.u2ghryme4xzxopi7@ad.chargestorm.se> From: Gary Thomas Message-ID: Date: Thu, 9 Feb 2017 09:04:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170209074907.u2ghryme4xzxopi7@ad.chargestorm.se> Subject: Re: sysroot question X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 08:05:08 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2017-02-09 08:49, Anders Darander wrote: > * Gary Thomas [170209 05:25]: >> On 2017-02-08 20:36, Paul Eggleton wrote: >>> I think the problem is that the task that prepares the sysroot >>> (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass >>> uses this: > >>> addtask make_scripts after do_prepare_recipe_sysroot before do_compile > >>> BTW you say you patterned your recipe after the skeleton example, except >>> hello-mod at least currently inherits module rather than module-base + kernel- >>> module-split - is there a compelling reason not to inherit module? > >> I may have been mistaken about the original source - it looks like I >> used a similar module strategy from meta-freescale. I did [just now] >> try using "inherit module" and the build dies a horrible death with >> this error >> | make: *** No rule to make target 'modules_install'. Stop. > > Well, that is simple to solve. module.bbclasses sets > > MODULES_INSTALL_TARGET ?= "modules_install" > > just override that with your own install target. (Or fix the module's > Makefile). The last option is to simply override do_install in your > recipe. I already override do_install(), so that's not enough. > >> I changed my [task] dependencies to match what you've quoted and everything >> works as before. !Thanks! > > I'd still recommend doing as little as possible in each recipe, and > leverage the standard modules. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------