Linux x64 binding exception

[jsorel]

Hello,

I am trying to use java bindings on linux x64 (fedora 40). but the .so fails to load in java with a good old exception :

Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/jni-1601019841721826404/libpdaljni.2.8.so: libpdalcpp.so.18: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type
	at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
	at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2399)
	at java.base/java.lang.Runtime.load0(Runtime.java:852)
	at java.base/java.lang.System.load(System.java:2030)

The file does exist, and is a valid x64 elf,

(base) jsorel@pc10:/tmp/jni-1601019841721826404$ readelf -h libpdaljni.2.8.so 
En-tête ELF:
  Magique:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
  Classe:                            ELF64
  Données:                          complément à 2, système à octets de poids faible d'abord (little endian)
  Version:                           1 (actuelle)
  OS/ABI:                            UNIX - GNU
  Version ABI:                       0
  Type:                              DYN (fichier objet partagé)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Adresse du point d'entrée:         0x0
  Début des en-têtes de programme :  64 (octets dans le fichier)
  Début des en-têtes de section :    176120 (octets dans le fichier)
  Fanions:                           0x0
  Taille de cet en-tête:             64 (octets)
  Taille de l'en-tête du programme:  56 (octets)
  Nombre d'en-tête du programme:     11
  Taille des en-têtes de section:    64 (octets)
  Nombre d'en-têtes de section:      32
  Table d'index des chaînes d'en-tête de section: 31

But it's a dynamic lib, not a static one.

When listing the native links in the .so we have :

(base) jsorel@pc10:/tmp/jni-1601019841721826404$ ldd libpdaljni.2.8.so
ldd: attention : vous n'avez pas la permission d'exécution pour `./libpdaljni.2.8.so'
	linux-vdso.so.1 (0x00007fd4c780c000)
	libpdalcpp.so.18 => not found
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fd4c7400000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd4c779b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fd4c721e000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fd4c76ba000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd4c780e000)

libpdalcpp.so.18 => not found

I believe this is why the so is not loaded, because a required lib is not available.

I tried installing PDAL on my machine, so I got pdal 2.5.6 (the latest one available on fedora 40) and downgraded the java binding to the closest version which is 2.5.1.

This time it loads but crashed a bit later :

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f5a7bb8238f, pid=28993, tid=28994
#
# JRE version: OpenJDK Runtime Environment Temurin-22.0.2+9 (22.0.2+9) (build 22.0.2+9)
# Java VM: OpenJDK 64-Bit Server VM Temurin-22.0.2+9 (22.0.2+9, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libpdal_base.so.15+0x38238f]  pdal::PipelineManager::validateStageOptions() const+0x1f
#

In it's current state the portable binding only works if you have the exact same version of PDAL already installed.

Would it be possible to have a release with a static build of PDAL java bindings for linux x64 ?

thank you

Johann

[pomadchin]

Hi! Thanks for reporting. That's a good question, should be not hard to do, most likely a flag. But I thought / think it's still treated as the 'x86' platform.

[pomadchin]

I believe this is why the so is not loaded, because a required lib is not available.

That is correct, PDAL-JNI is just PDAL bindings. Reading through the issue one more time.

But it's a dynamic lib, not a static one.

This is also true, we rely on the PDAL version and dynamically link. 👍

• Could you try the latest PDAL / bindings versions?
• What is the code that is running? Mb it's a bug of the older bindings overlapped with smth else.
  • 2.6.1 release had a couple of bug fixes around pipeline execution and stages validation: https://github.com/PDAL/java/releases/tag/v2.6.1 I would still recommend using the most up to date bindings.

[jsorel]

Hello,

Okay, I understand now, it's really just the JNI binding part. It makes sense that PDAL must be installed.
Anyway a static build would still be appreciated, in the java world we like things to be portable :). it could be a new artifact pdal-bundle.

I managed to get it working using version 2.5.1 of both.
Any change in the version of one or the other fails.

         <dependency>
            <groupId>io.pdal</groupId>
            <artifactId>pdal_3</artifactId>
            <version>2.5.1</version>
        </dependency>
         <dependency>
            <groupId>io.pdal</groupId>
            <artifactId>pdal-native</artifactId>
            <version>2.5.1</version>
        </dependency>

The code :

    public static void main(String[] args) throws Exception {

        String json =
        """
          {
            "pipeline":[
              {
                "type":"readers.copc",
                "filename":".../LHD_FXX_1062_6319_PTS_C_LAMB93_IGN69.copc.laz"
              },
                  {
                      "type":"writers.text",
                      "filename":"outputfile.txt"
                  }
            ]
          }
        """;

        Pipeline pipeline = new Pipeline(json, 8);
        pipeline.initialize();
        pipeline.validate();
        pipeline.execute();
        pipeline.close();
    }

But the result is empty, only the header is printed in the file

"X","Y","Z","Intensity","ReturnNumber","NumberOfReturns","ScanDirectionFlag","EdgeOfFlightLine","Classification","ScanAngleRank","UserData","PointSourceId","GpsTime","ScanChannel","ClassFlags"

No log or errors.

Am I missing something ?

[jsorel]

I build the latest PDAL on my machine and used the latest binding.
And finally have all my points with this version.

So the issue is closed for me.

On a more general concern :

There are small API changes between 2.5 > 2.6 > 2.8 so using the latest binding with older PDAL version will not work. This is a problem when we produce a tool for a client, since we can hardly have an exact match between the binding and the local installation of PDAL. Many users have limited control over what is installed and which version is or can be installed on the computer.

So the need for a static build is really important here if you want PDAL to be embedded in tools.

You think we could have a static portable build as a maven depedency ?

[pomadchin]

I like the idea of the static linking! Any PRs are super welcome & I'll try to assist as much as possible! Feel free to make a new feature issue.

As a workaround symlinking .so libs to satisfy dynamic linker works.

Things to keep in mind tho:

• The API changes are small, but the behavior changes are usually significant i.e. 2.5 and 2.6 are not behaving the same and there are changes in error handling due to underlying PDAL changes.

• Another example is gdal bindings we maintain, i.e. 3.1 is not really compatible with 3.7.

[pomadchin]

No log or errors.

Am I missing something ?

Have you tried PDAL CLI? Is it a PDAL bindings issue?
To help with it unfortunately I need access to the data (LHD_FXX_1062_6319_PTS_C_LAMB93_IGN69.copc.laz), and to have a reproducible example.

[jsorel]

No log or errors.
Am I missing something ?

Have you tried PDAL CLI? Is it a PDAL bindings issue? To help with it unfortunately I need access to the data (LHD_FXX_1062_6319_PTS_C_LAMB93_IGN69.copc.laz), and to have a reproducible example.

I made it work with 2.8, it's fine now.