• Jérome Perrin's avatar
    fixup! gdb: New component · ffc50ed4
    Jérome Perrin authored
    I tried to use this gdb in a software release installed by slapos-sr-testing (which perform some extra checks that we only do in slapos-sr-testing at the moment) and it complains that:
    
    ```
    ======================================================================
    ERROR: setUpModule (test)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/srv/slapgrid/slappart9/srv/slapos/soft/24930952d96110d7e0142b49eba918a8/parts/slapos.core-repository/slapos/testing/testcase.py", line 168, in setUpModule
        installSoftwareUrlList(cls, [software_url], debug=debug)
      File "/srv/slapgrid/slappart9/srv/slapos/soft/24930952d96110d7e0142b49eba918a8/parts/slapos.core-repository/slapos/testing/testcase.py", line 378, in installSoftwareUrlList
        checkSoftware(cls.slap, software_url)
      File "/srv/slapgrid/slappart9/srv/slapos/soft/24930952d96110d7e0142b49eba918a8/parts/slapos.core-repository/slapos/testing/testcase.py", line 336, in checkSoftware
        raise RuntimeError('\n'.join(error_list))
    RuntimeError: /srv/slapgrid/slappart9/srv/slapos/inst/slappart7/tmp/shared/gdb/d14016b094c3637c4ebf6a3df4a8c64d/bin/gdb uses system library /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.8 for libexpat.so.1
    
    ----------------------------------------------------------------------
    Ran 0 tests in 462.686s
    ```
    
    I saw this on a debian KVM on which I don't think I installed any system package except `slapos-node`, but `libexpat1-dev` is installed for some reason, so configure detected it and the built binary is linked against it. I checked some test nodes and `/usr/include/expat.h` seems present on some testnodes, so probably some test nodes will also have this problem. For that, I suggest to build a gdb using slapos `libexpat`, so that we build something more reproductible and not depending on the host system (that's important if we want to use binary cache, but can also be a problem if system packages get remove/upgraded). As you might be thinking now, that's a kind of infinite problem, because we can not add anything that configure might detect, but that's how we usually do for this for now.
    
    While looking at this, I also realised that we were using a .tar.xz URL here, for which rely our recipe will use `xz` command. Because some machines might not have that command, we usually put `xz-utils` in PATH.
    
    How about including something like this ?
    ffc50ed4
buildout.cfg 912 Bytes