Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Wolf Vollprecht
    @wolfv
    Hi @kunaltyagi the COS6 stands for centos 6 and cos7 for centos 7 (https://www.centos.org/)
    I don't think mixing and matching them would work
    but the linking to rt is something that seems to be related to centos 6 and it might be gone once we switch to a centos 7 "base"
    Kunal Tyagi
    @kunaltyagi
    Got it, makes sense.
    Wolf Vollprecht
    @wolfv
    however, unfortunately the centos team recently switched directions and doesn't want to produce super-stable Linux distributions that closely follow RedHat Enterprise anymore -- instead they want to make Centos Stream -- and now the conda-forge community doesn't know where to switch to :)
    there are some other alternatives like Rocky Linux or Alma Linux coming up but it will take a bit more time
    but I think if RoboStack would switch to Centos 7 it could simplify some things (such as this rt issue)
    btw you can also just do target_link_libraries(mytarget rt) etc.
    Kunal Tyagi
    @kunaltyagi
    Wolf Vollprecht
    @wolfv
    cool!
    Would it make sense to get depthai-core on conda-forge?
    Kunal Tyagi
    @kunaltyagi
    I don't know about that :) Not involved in that project as an owner
    And as a downstream developer it is moving quite fast, so I don't know how helpful that would be
    Tobias Fischer
    @Tobias-Fischer
    They have regular releases, and it's easy to setup an auto-merge on conda-forge, so it might make sense :)
    Tobias Fischer
    @Tobias-Fischer
    Very weird error on CI - any ideas?
    CMake Error at /opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/_build_env/share/cmake-3.21/Modules/CMakeTestCCompiler.cmake:69 (message):
      The C compiler
    
        "/opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/_build_env/bin/x86_64-conda-linux-gnu-cc"
    
      is not able to compile a simple test program.
    
      It fails with the following output:
    
        Change Dir: /opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/work/build/CMakeFiles/CMakeTmp
    
        Run Build Command(s):/opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/_build_env/bin/ninja cmTC_d260f && [1/2] Building C object CMakeFiles/cmTC_d260f.dir/testCCompiler.c.o
        FAILED: CMakeFiles/cmTC_d260f.dir/testCCompiler.c.o 
        /opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/_build_env/bin/x86_64-conda-linux-gnu-cc   -fdiagnostics-color=always -D__STDC_FORMAT_MACROS=1 -o CMakeFiles/cmTC_d260f.dir/testCCompiler.c.o -c /opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/work/build/CMakeFiles/CMakeTmp/testCCompiler.c
        /opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/_build_env/bin/x86_64-conda-linux-gnu-cc: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/conda/build_artifacts/ros-galactic-fmilibrary-vendor_1627593907410/_build_env/bin/x86_64-conda-linux-gnu-cc)
        ninja: build stopped: subcommand failed.
    Wolf Vollprecht
    @wolfv
    Shoot, I only an aware that new compilers were released a day ago or so
    Tobias Fischer
    @Tobias-Fischer
    Seems like it's pulling in packages from main rather than conda-forge: + gxx_impl_linux-64 9.3.0 hbdd7822_17 pkgs/main/linux-64 Cached
    Kunal Tyagi
    @kunaltyagi

    I've a weird issue:

    • During compilation, libudev.so.1 causes linker issues, so I have to rename it so it's not found
    • During execution, lack of libudev.so.1 causes runtime failure, so I have to rename it back

    Any solutions?

    Tobias Fischer
    @Tobias-Fischer
    libusb is installed?
    Kunal Tyagi
    @kunaltyagi
    Yes: libusb 1.0.24 h18f079d_4 conda-forge
    Tobias Fischer
    @Tobias-Fischer
    What error do you get during compilation?
    Kunal Tyagi
    @kunaltyagi
    Just reproduced:
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `memcpy@GLIBC_2.14'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `clock_gettime@GLIBC_2.17'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `fcntl64@GLIBC_2.28'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `getrandom@GLIBC_2.25'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `getauxval@GLIBC_2.16'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `reallocarray@GLIBC_2.26'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `gettid@GLIBC_2.30'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `name_to_handle_at@GLIBC_2.14'
    /opt/miniconda3/envs/ros1/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /opt/miniconda3/envs/ros1/lib/./libudev.so.0: undefined reference to `__explicit_bzero_chk@GLIBC_2.25'
    collect2: error: ld returned 1 exit status
    Tobias Fischer
    @Tobias-Fischer
    Ah yeah, I've seen this before
    Can you try doing something like this?
    For some reason we need to explicitly link to libudev when using conda-forge
    Kunal Tyagi
    @kunaltyagi
    Essentially, issue with libusb not linking to libudev?
    Tobias Fischer
    @Tobias-Fischer
    Yep

    The libusb-1.0.pc looks as

    Libs: -L${libdir} -lusb-1.0
    Libs.private: -ludev -lrt -lpthread

    Whereas it seems like it should be:

    Libs: -L${libdir} -lusb-1.0 -ludev
    Libs.private: -lrt -lpthread
    Kunal Tyagi
    @kunaltyagi
    Can this be rectified in conda-forge? It'd make things simpler :)
    And that also explains why only 2nd order dependencies have link errors and not the direct dependencies of libusb
    How can I access the conda-forge recipe? https://anaconda.org/conda-forge/libusb has no links to the code used to generate the binaries
    Tobias Fischer
    @Tobias-Fischer
    Yeah probably it should be fixed there, you are right!
    John Wason
    @wason1_gitlab
    I created a package for libbluetooth-headers. It contains header files for the bluez Linux library. It could probably be transferred to conda-forge. https://anaconda.org/robotraconteur/libbluetooth-headers feedstock: https://github.com/robotraconteur-conda/libbluetooth-headers-feedstock
    Wolf Vollprecht
    @wolfv
    @Tobias-Fischer I think conda forge switched to strict channel prio because of that problem
    We could also kick our defaults completely
    (The compiler problem)
    Silvio Traversaro
    @traversaro:matrix.org
    [m]
    Yep, that problem will highlight several place where defaults were still silently used, in the end it may be convenient : )
    Tobias Fischer
    @Tobias-Fischer
    Isn't it already strict for us, too?
    Silvio Traversaro
    @traversaro:matrix.org
    [m]
    I had a similar problem with setup-miniconda action, I am not sure if it is related (as there the setup-miniconda action is not used) but basically now I am explicitly purging the defaults channel
    Tobias Fischer
    @Tobias-Fischer
    Yes that fixed it: RoboStack/ros-galactic@a42688a
    Silvio Traversaro
    @traversaro:matrix.org
    [m]
    I think there is some kind of cross-talking between any conda installer you install in GitHub Actions (or also azure pipelines? not sure) and the default miniconda that they install themself
    Wolf Vollprecht
    @wolfv
    Possibly via ~/.condarc?
    @sitraversaro_twitter btw I am not sure if the „nodefaults“ channel works as intended with mamba
    If that’s what the CI is using