Can boost::filesystem be made to work on Nvidia Jetson (aarch64)

Question

I am trying to use Boost 1.76.0 on an Nvidia Jetson which according to lsb_release -rc has some Ubuntu 18.04 derivative on it and an ext4 filesystem.

Now when compiling the boost filesystem library

./bootstrap.sh --with-libraries=filesystem
./b2

this succeeds, but when I execute the tests

libs/filesystem/test/
../../../b2

I get a bunch of errors about Function not implemented:

====== BEGIN OUTPUT ======
BOOST_POSIX_API is defined
BOOST_FILESYSTEM_DECL=
BOOST_SYMBOL_VISIBLE=__attribute__((__visibility__("default")))
current_path() is /home/nvidia/boost_1_76_0/libs/filesystem/test
argv[1] is '/home/nvidia/boost_1_76_0/libs/filesystem/test', changing current_path() to it
current_path() is /home/nvidia/boost_1_76_0/libs/filesystem/test
temp_dir is /home/nvidia/boost_1_76_0/libs/filesystem/test/../op-unit_test-6911-1f1d-e324
file_status test...

ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR

****************************** std::exception *****************************
boost::filesystem::status: Function not implemented: "."
***************************************************************************


EXIT STATUS: 1
====== END OUTPUT ======

    LD_LIBRARY_PATH="/home/nvidia/boost_1_76_0/bin.v2/libs/filesystem/build/gcc-7/debug/threading-multi/visibility-hidden:/usr/bin:/usr/lib:/usr/lib32:/usr/lib64:$LD_LIBRARY_PATH
"
export LD_LIBRARY_PATH

    status=0
    if test $status -ne 0 ; then
        echo Skipping test execution due to testing.execute=off
        exit 0
    fi
     "../../../bin.v2/libs/filesystem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test" /home/nvidia/boost_1_76_0/libs/filesystem
/test  > "../../../bin.v2/libs/filesystem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test.output" 2>&1 < /dev/null
    status=$?
    echo >> "../../../bin.v2/libs/filesystem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test.output"
    echo EXIT STATUS: $status >> "../../../bin.v2/libs/filesystem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test.output"
    if test $status -eq 0 ; then
        cp "../../../bin.v2/libs/filesystem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test.output" "../../../bin.v2/libs/filesy
stem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test.run"
    fi
    verbose=0
    if test $status -ne 0 ; then
        verbose=1
    fi
    if test $verbose -eq 1 ; then
        echo ====== BEGIN OUTPUT ======
        cat "../../../bin.v2/libs/filesystem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test.output"
        echo ====== END OUTPUT ======
    fi
    exit $status

...failed testing.capture-output ../../../bin.v2/libs/filesystem/test/operations_unit_test.test/gcc-7/debug/threading-multi/visibility-hidden/operations_unit_test.run...
testing.capture-output ../../../bin.v2/libs/filesystem/test/copy_test.test/gcc-7/debug/threading-multi/visibility-hidden/copy_test.run

Specifically for my use case, the boost::filesystem::status seems to be the offender. It seems to me that this exception is raised here, but I'm not sure.

The initial output of ./b2 hints at some filesystem-related stuff not being available, but unfortunately I lack the knowledge to interpret this.

nvidia@nvidia-desktop:~/boost_1_76_0$ ./b2
Performing configuration checks

    - default address-model    : 64-bit (cached) [1]
    - default architecture     : arm (cached) [1]

Building the Boost C++ Libraries.


    - has stat::st_mtim        : yes (cached) [2]
    - has stat::st_mtimensec   : no  (cached) [2]
    - has stat::st_mtimespec   : no  (cached) [2]
    - has stat::st_birthtim    : no  (cached) [2]
    - has stat::st_birthtimensec : no  (cached) [2]
    - has stat::st_birthtimespec : no  (cached) [2]
    - has statx                : no  (cached) [2]
    - has statx syscall        : yes (cached) [2]
    - has stat::st_mtim        : yes (cached) [3]
    - has stat::st_mtimensec   : no  (cached) [3]
    - has stat::st_mtimespec   : no  (cached) [3]
    - has stat::st_birthtim    : no  (cached) [3]
    - has stat::st_birthtimensec : no  (cached) [3]
    - has stat::st_birthtimespec : no  (cached) [3]
    - has statx                : no  (cached) [3]
    - has statx syscall        : yes (cached) [3]

What is the reason that some filesystem functions would be unavailable on a system made of an ext4 filesystem and an Ubuntu 18.04 linux? Can this be patched without too much effort?

Depends on the libc you've got there. It will work on cross-compiled glibc just fine, but your system probably has a different variety (musl or whatever). — oakad, Aug 18 '21 at 08:07

Transformer · Answer 1 · 2021-08-26T04:55:32.490

Update 1: Response to your comment. I am trying to help you here, have you made any effort to read the Error output, or try the options I gave you.

Based on your below comment below that ..it does not address how to compile....

My answers gives you not 1 but 3 option/solutions to recompile to your specific target, with full reference documentations & turn key tool chains, in your case you can do it for ARM target.

Your question: ... some filesystem functions would be unavailable on a system made of an ext4 filesystem and an Ubuntu 18.04 linux? Can this be patched without too much effort?....

My answer in option 2, tries to give you a solution without too much effort so that you pull ahead of time or use already existing libs and compile .. more options on how to configure here..

It looks like you have put very little effort and not invested time to read or understand your own error messages.

Original Answer:

Based on your posted error message, your file/func/path seems to be an issue, its not finding the function/files; or unable to create test directories

option 1:

Suggestion make your life easier, by using something like Conan that allows easy cross compiling by leveraging profiles

easily cross-compile by plugging in the profile you select
switch or pick which version of Boost you want.
Best is that, it integrates really well with CMake

Option 2:

// try to use built in version of cmake, might take you back a version
set(BOOST_USE_STATIC_LIBS OFF)

This helps your configure your compile files dependencies, since your question you shared a concern on finding files vs caching some.., more here..

It maybe failing in the test section since its not able to create the directory as well.. make sure you give it permissions. Go here to see it on github

Option 3:

Completely remake/rebuild, I like this to ensure your tool chain has fresh and latest, but if you have custom paths etc, look further below

sudo apt-get install cmake libblkid-dev e2fslibs-dev libboost-all-dev libaudit-dev

if that still doesn't work, set up boost from cmake in a file... CMakeList.txt, as an example, update paths to your installation of boost.

SET (BOOST_ROOT "/opt/boost/boost_1_xx")
SET (BOOST_INCLUDEDIR "/opt/boost/boost-1.xx.0/include")
SET (BOOST_LIBRARYDIR "/opt/boost/boost-1.xx.0/lib")
SET (BOOST_MIN_VERSION "1.xx.0")
set (Boost_NO_BOOST_CMAKE ON)
FIND_PACKAGE(Boost ${BOOST_MIN_VERSION} REQUIRED)
if (NOT Boost_FOUND)
  message(FATAL_ERROR "Fatal error: Boost (version >= 1.xx) required.")
else()
  message(STATUS "Setting up BOOST")
  message(STATUS " Includes - ${Boost_INCLUDE_DIRS}")
  message(STATUS " Library  - ${Boost_LIBRARY_DIRS}")
  include_directories(${Boost_INCLUDE_DIRS})
  link_directories(${Boost_LIBRARY_DIRS})
endif (NOT Boost_FOUND)

searching default paths (/usr, /usr/local) or the path provided through the cmake variables (BOOST_ROOT, BOOST_INCLUDEDIR, BOOST_LIBRARYDIR)

Latest version is here with steps for the Linux (UNIX variants)

This answer appears to not address the question: It is not about how to include boost in a project, but compiling it from source on Arm64, with the result that some of boost's filesystem tests fail and some functionality is unavailable at runtime. — oarfish, Aug 24 '21 at 19:47
Look in option 2, it address some files that are cached vs. uncached, manually configure your files to avoid missing your dependencies on your arm64 `SET (BOOST_INCLUDEDIR "/opt/boost/boost-1.xx.0/include") SET (BOOST_LIBRARYDIR "/opt/boost/boost-1.xx.0/lib") SET (BOOST_MIN_VERSION "1.xx.0") set (Boost_NO_BOOST_CMAKE ON) FIND_PACKAGE(Boost ${BOOST_MIN_VERSION} REQUIRED) if (NOT Boost_FOUND) message(FATAL_ERROR "Fatal error: Boost (version >= 1.xx) required.")` — Transformer, Aug 26 '21 at 04:42
If the the options listed still doesn't work, let me know I will give you another soln.. I was able to compile it was a directory issue for me, I pulled everything locally and made sure I had all my dependencies to build and target both Arm 32 and 64 and it worked for me. — Transformer, Aug 26 '21 at 04:57

Can boost::filesystem be made to work on Nvidia Jetson (aarch64)

1 Answers1