All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
@ 2018-04-10  6:00 Thomas Petazzoni
  2018-04-10  8:15 ` Valentin Korenblit
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2018-04-10  6:00 UTC (permalink / raw)
  To: buildroot

Hello,

Build statistics for 2018-04-09
===============================

      branch |  OK | NOK | TIM | TOT |
   2018.02.x |  23 |   0 |   0 |  23 |
      master | 158 |  81 |   0 | 239 |

Results for branch 'master'
===========================

Classification of failures by reason
------------------------------------

                  zeromq-4.2.5 | 18
    azure-iot-sdk-c-2018-03-16 | 10
                     lxc-3.0.0 | 8 
                  host-go-1.10 | 5 
               libglib2-2.56.0 | 4 
                    liblo-0.29 | 4 
qt-webkit-kiosk-34efddb0bf0... | 3 
                  udftools-2.0 | 3 
             bluez5_utils-5.49 | 2 
             expect-2014-05-02 | 2 
                   flann-1.9.1 | 2 
gst1-interpipe-10dba89eecc2... | 2 
               libglib2-2.56.1 | 2 
                   picocom-3.1 | 2 
   python-yieldfrom-legal-info | 2 
               asterisk-14.7.6 | 1 
     docker-engine-v17.05.0-ce | 1 
                    llvm-5.0.1 | 1 
                 mesa3d-18.0.0 | 1 
                     php-7.2.4 | 1 
                      qt-4.8.7 | 1 
             qt5location-5.6.3 | 1 
               qt5webkit-5.9.1 | 1 
                snort-2.9.11.1 | 1 
          usb_modeswitch-2.5.2 | 1 
              wireshark-2.2.12 | 1 
                   woff2-1.0.2 | 1 


Detail of failures
------------------

         arc |                asterisk-14.7.6 | NOK | http://autobuild.buildroot.net/results/7b4bc90fdacf872a78f81664bba0135723f3a889 |     
      xtensa |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/461eafc0e4ae78131e24384305f41ed318c33a97 |     
     powerpc |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/f9c2c0bf2ddb95831d154de3046f159d0dd4d186 |     
      xtensa |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/e3381c9263283f629d1948b41c5791abfff32a9a |     
     aarch64 |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/d8b70efd1110e17a3fba4e870aa8afd283e652d1 |     
 powerpc64le |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/bcb4448f380060c552b12e75d8a26e1dfaad1bd5 |     
    mips64el |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/333ea0e44b7b9f84713de1c240ba164e06dd425d |     
         arm |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/25aae054634368fadb265b97ebe4dda809deff6f |     
         arm |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/14b4fcd442aff364339530ddcf879e2aa7428c36 |     
         arc |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/60b60a0b5a7dd02b25a1223aa7c66eb8df122834 |     
     powerpc |     azure-iot-sdk-c-2018-03-16 | NOK | http://autobuild.buildroot.net/results/bb64207f3b28ae971810c13d04ec44f4df1ebb3d |     
         arm |              bluez5_utils-5.49 | NOK | http://autobuild.buildroot.net/results/2b521f1954389dca3b52d3013c35ebfebcbccf75 |     
         arm |              bluez5_utils-5.49 | NOK | http://autobuild.buildroot.net/results/9ea3084be07e86ba60c848cb99587f375d2a5c47 |     
     aarch64 |      docker-engine-v17.05.0-ce | NOK | http://autobuild.buildroot.net/results/7b1c00518d36d2301608aff3b5010175ecd8256b |     
 powerpc64le |              expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/effdaafbaf09e9eeb05debd7b7ff116878617d73 | ORPH
      mipsel |              expect-2014-05-02 | NOK | http://autobuild.buildroot.net/results/3198daf050ce7de4b9afafb1ea3ecf979a2b1a00 | ORPH
     powerpc |                    flann-1.9.1 | NOK | http://autobuild.buildroot.net/results/132036fbe23310258d195fb2b917b4fbfc34ca0a |     
         arm |                    flann-1.9.1 | NOK | http://autobuild.buildroot.net/results/78502dbd16458358877549082551b6687cbd5d51 |     
    mips64el | gst1-interpipe-10dba89eecc2... | NOK | http://autobuild.buildroot.net/results/b552773cb79389abe2e9ce2876bc3b86ddddd0b4 |     
         sh4 | gst1-interpipe-10dba89eecc2... | NOK | http://autobuild.buildroot.net/results/61b9b5a416de0aa850f54c01e606671472e1f4bc |     
      x86_64 |                   host-go-1.10 | NOK | http://autobuild.buildroot.net/results/78d307376997f5f7fd2102c44417ba97c178e418 | ORPH
      x86_64 |                   host-go-1.10 | NOK | http://autobuild.buildroot.net/results/a55e708263b4ceb8db143a583a62bd7772a0e28c | ORPH
      x86_64 |                   host-go-1.10 | NOK | http://autobuild.buildroot.net/results/8214e2aa871d4774022e656634419d52ffeef50b | ORPH
      x86_64 |                   host-go-1.10 | NOK | http://autobuild.buildroot.net/results/8cf2e6995991dc319cb90fab6bc8f2732c931dbe | ORPH
      x86_64 |                   host-go-1.10 | NOK | http://autobuild.buildroot.net/results/ddc2caa833c4a06988a461f9c15ba5f0a8549a93 | ORPH
        or1k |                libglib2-2.56.0 | NOK | http://autobuild.buildroot.net/results/398490e07343a931b25ca6ab5c90a75d7a073e9f |     
        or1k |                libglib2-2.56.0 | NOK | http://autobuild.buildroot.net/results/0db2011d4dcca33105cc3e98657dab0c057773cd |     
        or1k |                libglib2-2.56.0 | NOK | http://autobuild.buildroot.net/results/10636fba5c16df8c56de9f27cb24431c17f78e34 |     
        or1k |                libglib2-2.56.0 | NOK | http://autobuild.buildroot.net/results/661e79cdd9ab87853e5f714006ec8fe7bf906a4f |     
        or1k |                libglib2-2.56.1 | NOK | http://autobuild.buildroot.net/results/13f3e792407dd6757939d63ae3c7a9549e1025a1 |     
        or1k |                libglib2-2.56.1 | NOK | http://autobuild.buildroot.net/results/9199c8f84c5d32670eb905cba38f2b33a8bf7de8 |     
        i586 |                     liblo-0.29 | NOK | http://autobuild.buildroot.net/results/029ae3a108a5ab0835355f194e49907be98857b0 | ORPH
      x86_64 |                     liblo-0.29 | NOK | http://autobuild.buildroot.net/results/7ceafdc2c46ff4d7ae8ad696be9aea5b339fb716 | ORPH
      x86_64 |                     liblo-0.29 | NOK | http://autobuild.buildroot.net/results/34edae2ed0a42d295abcf0d4f92af4725de6943b | ORPH
         arm |                     liblo-0.29 | NOK | http://autobuild.buildroot.net/results/6f97f11f8dc1d408bd988daf7b76513557ca070d | ORPH
         arm |                     llvm-5.0.1 | NOK | http://autobuild.buildroot.net/results/301c454c6eab802405a268f4713a574d1c366892 |     
         arm |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/fdf464a6679adf68739c50458f39857a230c287f |     
 powerpc64le |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/c7f11ccaf795573093b47108d0d2ca9d807a26ea |     
         arm |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/c89d544d159feb529ad6e02ce736ea98e87ee792 |     
         arm |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/dffeb98c3a52efe2a3cbaf83b2a6fb4d238561d9 |     
         arm |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/7c50a397db2aff4fe6bcfe6440966fcc624ee166 |     
         arm |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/9cc4331010b106182a0fdcc3143a1f8650a4d1ac |     
      x86_64 |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/778f378b9a17f4bb2bae5007a73204e23d1b6b53 |     
      xtensa |                      lxc-3.0.0 | NOK | http://autobuild.buildroot.net/results/2a1a2137f7dd2a12b5f929f384bfdd69a3115602 |     
      x86_64 |                  mesa3d-18.0.0 | NOK | http://autobuild.buildroot.net/results/b81c12d529c66a028e2297ea5ce1d6930324fa69 |     
    mips64el |                      php-7.2.4 | NOK | http://autobuild.buildroot.net/results/2a822b7cd07027e964bd04d4cb97fad156d52254 | ORPH
        i586 |                    picocom-3.1 | NOK | http://autobuild.buildroot.net/results/28ec584484dedfd6ef473dfd9dd24481e27ce2b3 |     
        i586 |                    picocom-3.1 | NOK | http://autobuild.buildroot.net/results/912493a8f99416524a5897634ae62604436e9b51 |     
    mips64el |    python-yieldfrom-legal-info | NOK | http://autobuild.buildroot.net/results/1672e19233316dffcc591ec467e9e43e07a066ca |     
         arc |    python-yieldfrom-legal-info | NOK | http://autobuild.buildroot.net/results/9b2e078c92f330261691513438128626e3e024b7 |     
     powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a277dd5b15b78671597357775282ee761593d237 | ORPH
     aarch64 | qt-webkit-kiosk-34efddb0bf0... | NOK | http://autobuild.buildroot.net/results/a1fa248bff809cf4283d50023d2984aacd868f6a |     
     aarch64 | qt-webkit-kiosk-34efddb0bf0... | NOK | http://autobuild.buildroot.net/results/faf8e56e01f983dddc252529377ffe9353ffc03e |     
         arm | qt-webkit-kiosk-34efddb0bf0... | NOK | http://autobuild.buildroot.net/results/e59e18b12fe4a2a15f1a54e06f199d6eca3e760c |     
     powerpc |              qt5location-5.6.3 | NOK | http://autobuild.buildroot.net/results/3210988f69d68c2146dd813c3cd7b5297bda6336 |     
      mipsel |                qt5webkit-5.9.1 | NOK | http://autobuild.buildroot.net/results/7bc8e2db13fed9b9348c950a98c6cc80893579b0 |     
       sparc |                 snort-2.9.11.1 | NOK | http://autobuild.buildroot.net/results/c364a9460ba0c20f5da5558ffadc854f1b595f7a |     
       sparc |                   udftools-2.0 | NOK | http://autobuild.buildroot.net/results/184c59b34376df72d591baac343d49a3103031bd |     
         arm |                   udftools-2.0 | NOK | http://autobuild.buildroot.net/results/f883d641f0c241cc999634e9ddd02b605ebe96cc |     
         arm |                   udftools-2.0 | NOK | http://autobuild.buildroot.net/results/88db3684eeb02527708f2c3cc1903d5cee5cae6f |     
microblazeel |           usb_modeswitch-2.5.2 | NOK | http://autobuild.buildroot.net/results/d2721890403ebc803aa3a9d0e6fbb80d111b8fde | ORPH
 powerpc64le |               wireshark-2.2.12 | NOK | http://autobuild.buildroot.net/results/8bf26fa9e483f48b3071d5a9a6e3998e8efce1e9 | ORPH
        m68k |                    woff2-1.0.2 | NOK | http://autobuild.buildroot.net/results/c8bd6d9177ec1f6175b8ff7a048556b3b2a43ec4 |     
       sparc |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/6c53d8048d5ad6190314c39e6e9c9c6b34792932 | ORPH
        m68k |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/05b97a07c6a67a750dec52aa9cffa128d2ad0fdc | ORPH
microblazeel |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/4ba07f105246321f560c9c393aaee038c23c26e5 | ORPH
       sparc |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/b8f29fefe27186cf646685dd01fabc5f6c210baf | ORPH
microblazeel |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/ba00d3a23827dacaf2a80dc6c80a81f0aae64c7e | ORPH
       sparc |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/23dfa3f277de151501abda807f43a7b9a92d9d90 | ORPH
        m68k |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/a986b77c56b974c730789c008ac2654e5357cd83 | ORPH
microblazeel |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/8ea02a07b9591536368304cb3e54975c9d6a7408 | ORPH
microblazeel |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/f7dde86af79d90c9785db6065a1ad38169e930ce | ORPH
         arm |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/e229979060fcfadd1bd6beddc5d47faaaf579d69 | ORPH
         arm |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/ab680546222a5059b42cf2120d97bccc24a2c055 | ORPH
        bfin |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/3fbf59d8dea36dad00ed268995a586862748f3a2 | ORPH
       sparc |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/9b968acde36dfb9431e36bd59897ae25426c39ca | ORPH
        m68k |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/303cf5c680c71511b105b8b23f3b3156a1d02d7c | ORPH
       sparc |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/cb361fdddf65a88c918938909c373f202f50e905 | ORPH
       sparc |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/45785c96a1bc8cfdb9f29c31eaa41c3e0773a654 | ORPH
       sparc |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/652f0087cdfe714e81b14a9d63869189e39fad50 | ORPH
         arm |                   zeromq-4.2.5 | NOK | http://autobuild.buildroot.net/results/f69df6d23c50f3f65593d298d7bd97462ccaa555 | ORPH


-- 
http://autobuild.buildroot.net

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
  2018-04-10  6:00 [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09 Thomas Petazzoni
@ 2018-04-10  8:15 ` Valentin Korenblit
  2018-04-10  8:23   ` Thomas Petazzoni
  0 siblings, 1 reply; 6+ messages in thread
From: Valentin Korenblit @ 2018-04-10  8:15 UTC (permalink / raw)
  To: buildroot

Hello all,

On 10/04/2018 08:00, Thomas Petazzoni wrote:
> Hello,
>
> Build statistics for 2018-04-09
> ===============================
>
> Results for branch 'master'
> ===========================
>
> Classification of failures by reason
> ------------------------------------
>
>                   mesa3d-18.0.0 | 1
>
> Detail of failures
> ------------------
>      
>        x86_64 |                  mesa3d-18.0.0 | NOK | http://autobuild.buildroot.net/results/b81c12d529c66a028e2297ea5ce1d6930324fa69 |
>
We have the following problem: llvm-config (host version installed in STAGING_DIR)
is not being able to link correctly with the libc of the host system. This happens
in the following scenario: target architecture = x86_64 and target libc != glibc
(assuming host system has glibc).

As the RPATH specifies $ORIGIN/../lib and the binary is located in STAGING_DIR/usr/bin,
it tries to link with the libc of the target, resulting in:

./llvm-config: error while loading shared libraries: libc.so.0: cannot open shared object file:
	No such file or directory.

It is important that llvm-config is located in STAGING, as it returns linker flags and
include directories relative to its location:

For example, when installed in STAGING_DIR/usr/bin:

./llvm-config --ldflags
-L/home/vakor/buildroot/output/host/x86_64-buildroot-linux-uclibc/sysroot/usr/lib

But when installed in HOST_DIR/bin

./llvm-config --ldflags
-L/home/vakor/buildroot/output/host/lib

The quick solution would be to change the RPATH to HOST_DIR/lib after copying it to STAGING,
so we'll also need either chrpath or patchelf. Otherwise, we can do a wrapper script in
STAGING that calls llvm-config from host, but this will have some outputs that are hardcoded
and will be more difficult to maintain in case llvm-config is modified in future versions.

I would like to know which would be an appropriate solution for this, any suggestions are
welcome.

Thanks in advance,

Valentin

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
  2018-04-10  8:15 ` Valentin Korenblit
@ 2018-04-10  8:23   ` Thomas Petazzoni
  2018-04-10  8:35     ` Valentin Korenblit
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2018-04-10  8:23 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 10 Apr 2018 10:15:29 +0200, Valentin Korenblit wrote:

> We have the following problem: llvm-config (host version installed in STAGING_DIR)
> is not being able to link correctly with the libc of the host system. This happens
> in the following scenario: target architecture = x86_64 and target libc != glibc
> (assuming host system has glibc).
> 
> As the RPATH specifies $ORIGIN/../lib and the binary is located in STAGING_DIR/usr/bin,
> it tries to link with the libc of the target, resulting in:

While the build is running, the rpath is not $ORIGIN/../lib. The RPATH
in the host and staging directories are only changed from an absolute
path to $ORIGIN/../lib in the "make sdk" target.

So while this will indeed cause a problem for llvm-config in the SDK
situation, I don't quite understand how you get this $ORIGIN/../lib
today, without running "make sdk".

> ./llvm-config: error while loading shared libraries: libc.so.0: cannot open shared object file:
> 	No such file or directory.
> 
> It is important that llvm-config is located in STAGING, as it returns linker flags and
> include directories relative to its location:
> 
> For example, when installed in STAGING_DIR/usr/bin:
> 
> ./llvm-config --ldflags
> -L/home/vakor/buildroot/output/host/x86_64-buildroot-linux-uclibc/sysroot/usr/lib
> 
> But when installed in HOST_DIR/bin
> 
> ./llvm-config --ldflags
> -L/home/vakor/buildroot/output/host/lib
> 
> The quick solution would be to change the RPATH to HOST_DIR/lib after copying it to STAGING,
> so we'll also need either chrpath or patchelf. Otherwise, we can do a wrapper script in
> STAGING that calls llvm-config from host, but this will have some outputs that are hardcoded
> and will be more difficult to maintain in case llvm-config is modified in future versions.
> 
> I would like to know which would be an appropriate solution for this, any suggestions are
> welcome.

One possibility is to do like we do for postgresql: provide our own
minimal -config script. See package/postgresql/pg_config for an example.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
  2018-04-10  8:23   ` Thomas Petazzoni
@ 2018-04-10  8:35     ` Valentin Korenblit
  2018-04-10  8:41       ` Thomas Petazzoni
  0 siblings, 1 reply; 6+ messages in thread
From: Valentin Korenblit @ 2018-04-10  8:35 UTC (permalink / raw)
  To: buildroot

Hello Thomas,

On 10/04/2018 10:23, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 10 Apr 2018 10:15:29 +0200, Valentin Korenblit wrote:
>
>> We have the following problem: llvm-config (host version installed in STAGING_DIR)
>> is not being able to link correctly with the libc of the host system. This happens
>> in the following scenario: target architecture = x86_64 and target libc != glibc
>> (assuming host system has glibc).
>>
>> As the RPATH specifies $ORIGIN/../lib and the binary is located in STAGING_DIR/usr/bin,
>> it tries to link with the libc of the target, resulting in:
> While the build is running, the rpath is not $ORIGIN/../lib. The RPATH
> in the host and staging directories are only changed from an absolute
> path to $ORIGIN/../lib in the "make sdk" target.
>
> So while this will indeed cause a problem for llvm-config in the SDK
> situation, I don't quite understand how you get this $ORIGIN/../lib
> today, without running "make sdk".

To be more precise, this is the RPATH:

(RPATH) Library rpath: [/home/vakor/buildroot/output/host/lib:$ORIGIN/../lib]

I haven't run make sdk.

>> ./llvm-config: error while loading shared libraries: libc.so.0: cannot open shared object file:
>> 	No such file or directory.
>>
>> It is important that llvm-config is located in STAGING, as it returns linker flags and
>> include directories relative to its location:
>>
>> For example, when installed in STAGING_DIR/usr/bin:
>>
>> ./llvm-config --ldflags
>> -L/home/vakor/buildroot/output/host/x86_64-buildroot-linux-uclibc/sysroot/usr/lib
>>
>> But when installed in HOST_DIR/bin
>>
>> ./llvm-config --ldflags
>> -L/home/vakor/buildroot/output/host/lib
>>
>> The quick solution would be to change the RPATH to HOST_DIR/lib after copying it to STAGING,
>> so we'll also need either chrpath or patchelf. Otherwise, we can do a wrapper script in
>> STAGING that calls llvm-config from host, but this will have some outputs that are hardcoded
>> and will be more difficult to maintain in case llvm-config is modified in future versions.
>>
>> I would like to know which would be an appropriate solution for this, any suggestions are
>> welcome.
> One possibility is to do like we do for postgresql: provide our own
> minimal -config script. See package/postgresql/pg_config for an example.

I'll take a look.

> Best regards,
>
> Thomas

Thanks,

Valentin

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
  2018-04-10  8:35     ` Valentin Korenblit
@ 2018-04-10  8:41       ` Thomas Petazzoni
  2018-04-10  9:02         ` Valentin Korenblit
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2018-04-10  8:41 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 10 Apr 2018 10:35:34 +0200, Valentin Korenblit wrote:

> > So while this will indeed cause a problem for llvm-config in the SDK
> > situation, I don't quite understand how you get this $ORIGIN/../lib
> > today, without running "make sdk".  
> 
> To be more precise, this is the RPATH:
> 
> (RPATH) Library rpath: [/home/vakor/buildroot/output/host/lib:$ORIGIN/../lib]
> 
> I haven't run make sdk.

Meh. Then either I no longer understand how Buildroot works, or it's
the LLVM build system that adds $ORIGIN/../lib in the RPATH.

But I believe your situation highlights a larger problem: we currently
use all <foo>-config scripts in STAGING_DIR because that's where
libraries install them, but that only works because all those programs
are scripts, and not compiled programs.

With compiled programs, it indeed doesn't work well to have host
binaries in STAGING_DIR, due to the RPATH issues. I'm not sure how to
solve this. Should we have all those <foo>-config programs in a
separate location ? But apparently, this llvm-config program behaves
different depending on its location, so if we move it elsewhere, it
won't return the right results anymore.

> > One possibility is to do like we do for postgresql: provide our own
> > minimal -config script. See package/postgresql/pg_config for an example.  
> 
> I'll take a look.

If the output returned by llvm-config is relatively simple, and it
doesn't have gazillion of options, then it is probably the easiest
solution.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09
  2018-04-10  8:41       ` Thomas Petazzoni
@ 2018-04-10  9:02         ` Valentin Korenblit
  0 siblings, 0 replies; 6+ messages in thread
From: Valentin Korenblit @ 2018-04-10  9:02 UTC (permalink / raw)
  To: buildroot

Hello,

On 10/04/2018 10:41, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 10 Apr 2018 10:35:34 +0200, Valentin Korenblit wrote:
>
>>> So while this will indeed cause a problem for llvm-config in the SDK
>>> situation, I don't quite understand how you get this $ORIGIN/../lib
>>> today, without running "make sdk".
>> To be more precise, this is the RPATH:
>>
>> (RPATH) Library rpath: [/home/vakor/buildroot/output/host/lib:$ORIGIN/../lib]
>>
>> I haven't run make sdk.
> Meh. Then either I no longer understand how Buildroot works, or it's
> the LLVM build system that adds $ORIGIN/../lib in the RPATH.

It is effectively LLVM that modifies the RPATH in AddLLVM.cmake:

https://pastebin.com/JGWrsLsi

I'll try to patch this file to see if we can get it working.

> But I believe your situation highlights a larger problem: we currently
> use all <foo>-config scripts in STAGING_DIR because that's where
> libraries install them, but that only works because all those programs
> are scripts, and not compiled programs.

Yes, we were discussing this yesterday with Romain, in general they are scripts.

> With compiled programs, it indeed doesn't work well to have host
> binaries in STAGING_DIR, due to the RPATH issues. I'm not sure how to
> solve this. Should we have all those <foo>-config programs in a
> separate location ? But apparently, this llvm-config program behaves
> different depending on its location, so if we move it elsewhere, it
> won't return the right results anymore.

At least for llvm-config, we cannot move it to other place. I don't know
if there are any other packages that deal with the same kind of problem.

>>> One possibility is to do like we do for postgresql: provide our own
>>> minimal -config script. See package/postgresql/pg_config for an example.
>> I'll take a look.
> If the output returned by llvm-config is relatively simple, and it
> doesn't have gazillion of options, then it is probably the easiest
> solution.
>
> Best regards,
>
> Thomas

Thanks,

Valentin

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-04-10  9:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-10  6:00 [Buildroot] [autobuild.buildroot.net] Build results for 2018-04-09 Thomas Petazzoni
2018-04-10  8:15 ` Valentin Korenblit
2018-04-10  8:23   ` Thomas Petazzoni
2018-04-10  8:35     ` Valentin Korenblit
2018-04-10  8:41       ` Thomas Petazzoni
2018-04-10  9:02         ` Valentin Korenblit

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.