We have a deps section in our CI yaml that looks something like what’s below. It looks like you are missing the rust tool chain, cargo deps fetch and rust compilation steps.

  deps:
    name: Dependencies
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          submodules: true

      - name: Setup Elixir
        uses: erlef/setup-beam@v1
        with:
          version-file: .tool-versions
          version-type: strict

      - name: Setup Rust
        uses: dtolnay/rust-toolchain@stable
        with:
          toolchain: stable

      - name: Retrieve Mix dependencies
        uses: actions/cache@v4
        id: cache-compiled-deps
        with:
          path: |
            deps
            _build
          key: ${{ runner.os }}-${{ env.MIX_ENV }}-${{ hashFiles('mix.lock') }}-v2

      - name: Retrieve Cargo dependencies
        uses: Swatinem/rust-cache@v2
        with:
          cache-on-failure: true
          shared-key: rustler-v2
          workspaces: native/imagesize -> target

      - name: Install Mix dependencies
        run: mix deps.get

      - name: Compile Mix dependencies.
        run: mix deps.compile

      - name: Compile Rust dependencies
        working-directory: native/imagesize
        run: cargo build --profile release

      - name: Create Dialyzer PLT files
        run: mix dialyzer --plt
        if: ${{ false }}

Hey there.

I think your setup would work with a simpler rust library because looking at your CI output you can see that rust dependencies are downloaded and rust is also compiling stuff.

The extractous rust library is doing (compiling) stuff with GraalVM because of Apache Tika, see extractous/extractous-core/README.md at main · yobix-ai/extractous · GitHub

I also don’t get it running locally, even with a newer rustler version with the deprecations fixed and a GraalVM Java SDK available.

It compiles without errors but also fails with the same Failed to load NIF library error.

Maybe someone has an idea what happens with the libtika_native.so file and how to handle it with a rustler setup.

@codestirring I think you are the article author? Can you tell us how you were able to get it running?

Thx

Cheers
Frank

A little more investigation…

 ldd _build/prod/rel/**/priv/native/libdoc_extractor.so

	linux-vdso.so.1 (0x0000ffff82483000)
	libtika_native.so => not found
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffff82380000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff821d0000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff8244a000)

So it is just that one libtika_native.so binary. Nothing else. Extending the build process seems like a good path here.

{:nif_extractous, github: "snewcomer/nif-extractous"},

NifExtractous.Native.extract_document(local_path)

Hey!

I had recently same issue with extractous. My solution was to copy libtika_native.so and any other lib that is used by extractous to /app/priv/native/ and then point this path in LD_LIBRARY_PATH

I’m doing this like that:

RUN find /app/_build -name libtika_native.so -exec sh -c 'cp $(dirname {})/*.so /app/priv/native/' \;
ENV LD_LIBRARY_PATH=/app/priv/native

It’s working for me in dev env and currently I’m trying to make it work with mix release as well.

Just tested, and same thing works for mix release, I copied all the needed .so from build layer into the runner and point LD_LIBRARY_PATH to the directory

COPY --from=builder --chown=nobody:root /app/native native

ENV LD_LIBRARY_PATH=/app/native:$LD_LIBRARY_PATH