Help Needed - trouble with rpath and rpath-link

[th0ma7]

I'm one of the developper for the spksrc SynoCommunity framework which allows compiling and packaging opensource software that can then be installed on Synology NAS. I've been struggling with a specific case with meson with regards to proper handling of rpath/rpath-link that I use in different other ways.

Associated PR SynoCommunity/spksrc#6454

My classic use-case is such as having something such as the following containing multiple --rpath and --rpath-link:

LDFLAGS="-L/home/spksrc/wheel-meson2/spksrc/toolchain/syno-x64-7.1/work/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/lib -L/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib -Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib -Wl,--rpath,/var/packages/python312-wheels/target/lib -L/home/spksrc/wheel-meson2/spksrc/spk/python312/work-x64-7.1/install/var/packages/python312/target/lib -Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312/work-x64-7.1/install/var/packages/python312/target/lib -Wl,--rpath,/var/packages/python312/target/lib"

I'm generating package specific meson cross-file when needed whereas I tried converting my LDFLAGS such as using c_link_args array, also tried using install_rpath and build_rpath string list but I do not get the expected result. Example:

[properties]
install_rpath = '/var/packages/python312-wheels/target/lib:/var/packages/python312/target/lib:'
... 

or

c_link_args = [
        '-L/home/spksrc/wheel-meson2/spksrc/toolchain/syno-x64-7.1/work/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/lib',
        '-L/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib',
        '-Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib',
        '-Wl,--rpath,/var/packages/python312-wheels/target/lib',
        '-L/home/spksrc/wheel-meson2/spksrc/spk/python312/work-x64-7.1/install/var/packages/python312/target/lib',
        '-Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312/work-x64-7.1/install/var/packages/python312/target/lib',
        '-Wl,--rpath,/var/packages/python312/target/lib',
        ]

Generated binaries, not using meson (such as automake or our generated cmake cross-file) will return something such as the following where rpath depth 1 is matching expected host installation directories (using libtree -vvv -p to get info):

└── libfuse.so.2 not found
    ┊ Paths considered in this order:
    ┊ 1. rpath:
    ┊    depth 1
    ┊    /var/packages/python312-wheels/target/lib
    ┊    /var/packages/python312/target/lib
    ┊ 2. LD_LIBRARY_PATH was not set
    ┊ 3. runpath was not set
    ┊ 4. ld config files:
    ┊    /usr/lib/x86_64-linux-gnu/libfakeroot
    ┊    /usr/local/lib
    ┊    /usr/local/lib/x86_64-linux-gnu
    ┊    /lib/x86_64-linux-gnu
    ┊    /usr/lib/x86_64-linux-gnu
    ┊    /lib32
    ┊    /usr/lib32
    ┊    /libx32
    ┊    /usr/libx32
    ┊ 5. Standard paths:
    ┊    /lib
    ┊    /lib64
    ┊    /usr/lib
    ┊    /usr/lib64

Below is the behavior obtained with my meson cross-file:

│   └── libgfortran.so.5 not found
│       ┊ Paths considered in this order:
│       ┊ 1. rpath:
│       ┊    depth 2
│       ┊    /var/packages/python312-wheels/target/lib
│       ┊    /var/packages/python312/target/lib
│       ┊    depth 1
│       ┊    /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib
│       ┊ 2. LD_LIBRARY_PATH was not set
│       ┊ 3. runpath was not set
│       ┊ 4. ld config files:
│       ┊    /usr/lib/x86_64-linux-gnu/libfakeroot
│       ┊    /usr/local/lib
│       ┊    /usr/local/lib/x86_64-linux-gnu
│       ┊    /lib/x86_64-linux-gnu
│       ┊    /usr/lib/x86_64-linux-gnu
│       ┊    /lib32
│       ┊    /usr/lib32
│       ┊    /libx32
│       ┊    /usr/libx32
│       ┊ 5. Standard paths:
│       ┊    /lib
│       ┊    /lib64
│       ┊    /usr/lib
│       ┊    /usr/lib64

End result being inability to load needed .so once installed on host.

Help would be really much appreciated, thnx in advance.

[th0ma7]

May be related to #6541

TL;DR

As there is no equivalent to PKG_CONFIG_LIBDIR in meson config, I must set it in my environment. When doing so it screws-up my rpath definition in resulting libraries whereas rpath is defined for my build environment, and not for my destination host.

Solution is two-fold:

1. First, use libtree -vvv -p instead -f readelf -d will show rpath depth 1 and depth 2 whereas depth 2 contains my actual destination host rpath, but stays hiden due to build rpath being set in depth 1. --- readelf doesn't show that, or haven't found how.
2. Also declare a LDFLAGS with associated rpath. Yes, its a complete duplicate from install_rpath and build_rpath in my cross-file, although it hapens to add my destination host rpath to depth 1 which makes the libraries to work. Still, destination rpath are also duplicated in depth 2 (shown with libtree) and the uneeded build rpath is still showing in depth 1.

longer-version

I was able to gather more details surrouding this issue, at least a potential workaround...

What I notice is that as soon as I use PKG_CONFIG_LIBDIR to enforce pkgconfig location of my cross-compile environment, meson ends-up screwing my rpath in my generated .so library files. My actual rpath from install_rpath variable becomes hiden using readelf -d as being in depth 2.

Here's readelf -d:

$ readelf -d numpy/linalg/lapack_lite.cpython-312-x86_64-linux-gnu.so

Dynamic section at offset 0x3e00 contains 23 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libopenblas.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [/var/packages/python312-wheels/target/lib:/var/packages/python312/target/lib:/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib]
 0x000000000000000c (INIT)               0x10a8
 0x000000000000000d (FINI)               0x2478
 0x0000000000000004 (HASH)               0x190
 0x000000006ffffef5 (GNU_HASH)           0x368
 0x0000000000000005 (STRTAB)             0x7c8
 0x0000000000000006 (SYMTAB)             0x3c0
 0x000000000000000a (STRSZ)              880 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x204000
 0x0000000000000002 (PLTRELSZ)           624 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0xe38
 0x0000000000000007 (RELA)               0xbb0
 0x0000000000000008 (RELASZ)             648 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0xb90
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0xb38
 0x000000006ffffff9 (RELACOUNT)          17
 0x0000000000000000 (NULL)               0x0

And here's when using libtree -vvv -p:

• Note1: Below it should not find libopenblas.so.0 when looking at libs from my build environment as that rpath should not be existing.
• Note2: Below it doesn't find libgfortran.so.5 as normally expected (will exist only on destination host). Although associated rpath are wrong, showing build rpath as depth 1 and destination host rpath as depth 2.

$ libtree -vvv -p  numpy/linalg/lapack_lite.cpython-312-x86_64-linux-gnu.so
numpy/linalg/lapack_lite.cpython-312-x86_64-linux-gnu.so 
├── /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib/libopenblas.so.0 [rpath]
│   ├── /lib/x86_64-linux-gnu/libm.so.6 [ld.so.conf]
│   │   ├── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   ├── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   ├── /lib/x86_64-linux-gnu/libquadmath.so.0 [ld.so.conf]
│   │   ├── /lib/x86_64-linux-gnu/libm.so.6 [ld.so.conf]
│   │   │   ├── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │   │   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   │   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │       └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   ├── /lib/x86_64-linux-gnu/libgcc_s.so.1 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │       └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   └── libgfortran.so.5 not found
│       ┊ Paths considered in this order:
│       ┊ 1. rpath:
│       ┊    depth 2
│       ┊    /var/packages/python312-wheels/target/lib
│       ┊    /var/packages/python312/target/lib
│       ┊    depth 1
│       ┊    /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib
│       ┊ 2. LD_LIBRARY_PATH was not set
│       ┊ 3. runpath was not set
│       ┊ 4. ld config files:
│       ┊    /usr/lib/x86_64-linux-gnu/libfakeroot
│       ┊    /usr/local/lib
│       ┊    /usr/local/lib/x86_64-linux-gnu
│       ┊    /lib/x86_64-linux-gnu
│       ┊    /usr/lib/x86_64-linux-gnu
│       ┊    /lib32
│       ┊    /usr/lib32
│       ┊    /libx32
│       ┊    /usr/libx32
│       ┊ 5. Standard paths:
│       ┊    /lib
│       ┊    /lib64
│       ┊    /usr/lib
│       ┊    /usr/lib64
└── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
    └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
Error [numpy/linalg/lapack_lite.cpython-312-x86_64-linux-gnu.so]: Not all dependencies were found

Dirty fix being, if I also declare a LDFLAGS variable my rpath do appear in both depth 1 and depth 2, and therefore path gets properly identified on destination host. Still, the unrelated rpath from from build is still there.

Here's what it looks like with LDFLAGS set:

libtree -vvv -p  numpy/linalg/lapack_lite.cpython-312-x86_64-linux-gnu.so
numpy/linalg/lapack_lite.cpython-312-x86_64-linux-gnu.so 
├── /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib/libopenblas.so.0 [rpath]
│   ├── /lib/x86_64-linux-gnu/libm.so.6 [ld.so.conf]
│   │   ├── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   ├── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   ├── /lib/x86_64-linux-gnu/libquadmath.so.0 [ld.so.conf]
│   │   ├── /lib/x86_64-linux-gnu/libm.so.6 [ld.so.conf]
│   │   │   ├── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │   │   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   │   │   └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │       └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   ├── /lib/x86_64-linux-gnu/libgcc_s.so.1 [ld.so.conf]
│   │   └── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
│   │       └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
│   └── libgfortran.so.5 not found
│       ┊ Paths considered in this order:
│       ┊ 1. rpath:
│       ┊    depth 2
│       ┊    /var/packages/python312-wheels/target/lib
│       ┊    /var/packages/python312/target/lib
│       ┊    depth 1
│       ┊    /var/packages/python312-wheels/target/lib
│       ┊    /var/packages/python312/target/lib
│       ┊    /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib
│       ┊ 2. LD_LIBRARY_PATH was not set
│       ┊ 3. runpath was not set
│       ┊ 4. ld config files:
│       ┊    /usr/lib/x86_64-linux-gnu/libfakeroot
│       ┊    /usr/local/lib
│       ┊    /usr/local/lib/x86_64-linux-gnu
│       ┊    /lib/x86_64-linux-gnu
│       ┊    /usr/lib/x86_64-linux-gnu
│       ┊    /lib32
│       ┊    /usr/lib32
│       ┊    /libx32
│       ┊    /usr/libx32
│       ┊ 5. Standard paths:
│       ┊    /lib
│       ┊    /lib64
│       ┊    /usr/lib
│       ┊    /usr/lib64
└── /lib/x86_64-linux-gnu/libc.so.6 [ld.so.conf]
    └── /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 [ld.so.conf]
Error [numpy/linalg/lapack_lite.cpython-312-x86_64-linux-gnu.so]: Not all dependencies were found

[th0ma7]

Adding a few more comments as I've been doing more testing to try to identify permutations... Here's the comments I've added to my build code:

# Also due to meson bug, keep LDFLAGS for rpath management.
# This only occurs when there are multiple rpath definitions.
# Ref: https://github.com/mesonbuild/meson/issues/14354
#      https://github.com/mesonbuild/meson/issues/6541
#
# Note0: The only way to get rpath defined in resulting *.so
#        is from using LDFLAGS variable part of environment.
# Note1: Adding options --enable-new-dtags or --strip-all to
#        *_link_args has no effect on resulting rpath and runpath.
# Note2: Defining build_rpath and install_rpath has no effect.
#        It should normally affect the runpath and not the rpath.
# Note3: Similarly, re-defining -Wl,--rpath-link and -Wl,--rpath
#        part of *_link_args has no effect neither as LDFLAGS
#        needs to be set anyway and already has rpath defined.
# Note4: Defining runpath (instead of rpath) using install_rpath
#        or -Wl,--enable-new-dtags has no effect neither.

[eli-schwartz]

I don't have any idea what you are trying to ask.

Here are some things that stand out to me:

• cross files don't have an install_rpath property so I don't know why you are trying to set one, but it certainly won't work
• PKG_CONFIG_LIBDIR has no influence at all on rpath, except inasmuch as PKG_CONFIG_LIBDIR can cause dependencies to find different *.pc files and those *.pc files might contain the literal text content -Wl,--rpath (but generally should not)
• what is "rpath depth 1" and "rpath depth 2"? It is not part of the ELF specification. I don't know why you think they are "duplicated", nor why they should or shouldn't be so. Since "depth" doesn't exist, readelf naturally cannot show it

Now, to back up a step:

If you add LDFLAGS containing a linker flag -Wl,-rpath then meson should see that and build all artifacts using it. This will be preserved as you specified it.

Authors of a meson.build can set per-target rpaths based on their own install layout, usually related to how internal plugins work. Those will be preserved as well.

At build time, some additional rpaths are added in order to smooth over the needs of build-time usage and testsuite invocation, which you should not be depending on at all -- it is not useful once you installed the project to have rpaths such as /home/eschwartz/git/foo-project/builddir-debug/src/util. So just... don't worry about that.

Now:

• What rpath did you want to see?
• How did you define it?
• You said that the output of readelf -d is 0x000000000000000f (RPATH) Library rpath: [/var/packages/python312-wheels/target/lib:/var/packages/python312/target/lib:/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-x64-7.1/install/var/packages/python312-wheels/target/lib]. Is that correct?

[th0ma7]

Thnx @eli-schwartz for your answer, much appreciated.

I'll try to provide additional context: spksrc framework is meant to allow download + cross-compiling opensource software and generate Synology DSM Linux NAS compatible packages redistributed from our SynoCommunity package server https://synocommunity.com/packages

Synology provides a toolchain package for each supported DSM Linux versions (refered as DSM6 and DSM7) for each supported archs (armv5, armv7, armv8, ppc, i686 and x86_64). We use a x86_64 container build environement and cross-compile to said host arch by pointing to related gcc+binutils+glibc+sysroot as provided by the toolchain packages.

Framework support autotools, cmake and meson. By default it populates the environment with all mandatory autotools *FLAGS and for each dependencies needed to be compiled part of a resulting package, generates a cmake toolchain file or meson cross-file as needed. If applicable (i.e. for source package not using autotools), the generated toolchain-file/cross-file is passed to either cmake/meson at configure time along with emptying the environment from any autotools redundant environment variables to avoid any conflicts/duplicates.

To be clear, issue I found is when having multiple rpath defined part of my resulting LDFLAGS.

single rpath case (the good)

My regular use-case only has a single rpath-link + rpath defined part of my LDFLAGS such as:

LDFLAGS="-L/home/spksrc/wheel-meson2/spksrc/toolchain/syno-aarch64-7.1/work/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/lib \
         -L/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib \
         -Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib \
         -Wl,--rpath,/var/packages/python312-wheels/target/lib \
         $(ADDITIONAL_LDFLAGS)"

Whereas:

• -L/home/spksrc/wheel-meson2/spksrc/toolchain/syno-aarch64-7.1/work/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/lib refers to Synology toolchain installation library path
• -L/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib refers to my work directory + installation prefix library path
  --Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib refers to my build-time rpath pointing to my directory + installation prefix library path
• -Wl,--rpath,/var/packages/python312-wheels/target/lib refers to destination host rpath to be used when said cross-compiled file are actually installed on Synology NAS. This really is the rpath I want to see.

I can either:

1. add them in build_rpath or install_rpath defined in [properties] (if I recall this affects the RUNPATH, similarly to passing -Wl,--enable-new-dtags)
2. add them in all corresponding *_link_args
3. or simply keep the LDFLAGS environment variable which contains said rpath definitions.

In all cases it simply works, no issue to be found.

multiple rpath case (the bad)

When I end-up having multiple rpath defined part of the LDFLAGS such as:

LDFLAGS="-L/home/spksrc/wheel-meson2/spksrc/toolchain/syno-aarch64-7.1/work/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/lib \
         -L/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib \
         -Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312/work-aarch64-7.1/install/var/packages/python312/target/lib \
         -Wl,--rpath,/var/packages/python312/target/lib \
         -Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib \
         -Wl,--rpath,/var/packages/python312-wheels/target/lib"

I expect my end-state rpath to be such as (using readelf -d):

 0x000000000000000f (RPATH)              Library rpath: [/var/packages/python312/target/lib:/var/packages/python312-wheels/target/lib]

But when only using either only build_rpath OR install_rpath defined in [properties] or *_link_args including -Wl,--rpath, + -Wl,--rpath-link, (e.g. LDFLAGS not set in my environment) I rather get one of my build-time rpath:

 0x000000000000000f (RPATH)              Library rpath: [/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib]

While investigating where this is coming from I noticed that I could remove all rpath definition from my meson cross-file as in reality this seems to somehow to be getting included when PKG_CONFIG_LIBDIR is defined (which is mandatory in my build environment). But let's keep that aside for now.

I recall another tool called libtree that provide more details surrounding rpath/runpath internals whend using libtree -vvv -p <lib.so>. Using that tool I noticed the following:

│       ┊ 1. rpath:
│       ┊    depth 2
│       ┊    /var/packages/python312-wheels/target/lib
│       ┊    /var/packages/python312/target/lib
│       ┊    depth 1
│       ┊    /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib
│       ┊ 2. LD_LIBRARY_PATH was not set
│       ┊ 3. runpath was not set

Don't get me wrong, I have no clue what depth 1 or 2 are for, neither wetter it's part of the specifications. I just hapened.

A workaround that was to:

1. NOT use build_rpath or install_rpath
2. NOT include -Wl,--rpath, + -Wl,--rpath-link, into *_link_args
3. ALWAYS keep LDFLAGS environment variable set containing all -Wl,--rpath, + -Wl,--rpath-link,

This switched things such as using readelf:

 0x000000000000000f (RPATH)              Library rpath: [/var/packages/python312-wheels/target/lib:/var/packages/python312/target/lib:/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib]

And using libtree:

    ┊ 1. rpath:
    ┊    depth 1
    ┊    /var/packages/python312-wheels/target/lib
    ┊    /var/packages/python312/target/lib
    ┊    /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib
    ┊ 2. LD_LIBRARY_PATH was not set
    ┊ 3. runpath was not set

With that I do have my multiple rpath properly set, and it works when used on my target NAS installation environment. Although I still have a wrong rpath also defined for unknown reason.

Other insights (not really the ugly but keeping the moving theme)

• As for PKG_CONFIG_LIBDIR, I absolutely need that in my environment as I don't want my cross-compilation to be polluted from build system libraries. At first I tried using [properties] / pkg_config_path but it looks like adding that path to the system's default pkg path and could not find any meson declaration equivalent to PKG_CONFIG_LIBDIR.
• cpp definition (unrelated to this discussion but something else I also noted) - Most of the time the meson configure will fail if pointing to my actual cross-environment cpp binary. Making it to point to g++ solved that (I have no recollection where I found that...)

And lastly here's an example of my autogenerated meson cross-file:
aarch64-crossfile.meson.txt

To conlude, I do have a workaround that "works" even though resulting libraries contains an invalid rpath part of it rpath list.
Although I'd rather have a solution that fix that entirely.

I presume my issue is an oversight from my part, but any guidance would be welcomed.

[eli-schwartz]

build numpy/_core/_multiarray_umath.cpython-312-aarch64-linux-gnu.so: cpp_LINKER numpy/_core/_multiarray_umath.cpython-312-aarch64-linux-gnu.so.p/meson-generated_arraytypes.c.o numpy/_core/_multiarray_umath.cpython-312-aarch64-linux-gnu.so.p/meson-generated_einsum.c.o [...]

 LINK_ARGS = -Wl,--as-needed -Wl,--allow-shlib-undefined -Wl,-O1 -shared -fPIC -Wl,-rpath,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib -Wl,-rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib -Wl,--start-group numpy/_core/libnpymath.a numpy/_core/lib_multiarray_umath_mtargets.a numpy/_core/libhighway.a /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib/libopenblas.so -Wl,--end-group

Let's format those LINK_ARGS a bit better:

$ printf '<%s>\n'  -Wl,--as-needed -Wl,--allow-shlib-undefined -Wl,-O1 -shared -fPIC -Wl,-rpath,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib -Wl,-rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib -Wl,--start-group numpy/_core/libnpymath.a numpy/_core/lib_multiarray_umath_mtargets.a numpy/_core/libhighway.a /home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib/libopenblas.so -Wl,--end-group

<-Wl,--as-needed>
<-Wl,--allow-shlib-undefined>
<-Wl,-O1>
<-shared>
<-fPIC>
<-Wl,-rpath,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib>
<-Wl,-rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib>
<-Wl,--start-group>
<numpy/_core/libnpymath.a>
<numpy/_core/lib_multiarray_umath_mtargets.a>
<numpy/_core/libhighway.a>
</home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib/libopenblas.so>
<-Wl,--end-group>

I see only one rpath argument passed to the linker.

Also,

Build Options: -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md -Dblas=OpenBLAS --cross-file=/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/numpy-2.2.3/numpy.meson --cross-file=/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/numpy-2.2.3/aarch64-crossfile.meson --native-file=/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/numpy-2.2.3/builddir/meson-python-native-file.ini

Where is numpy-2.2.3/numpy.meson ?

[th0ma7]

It is actually called aarch64-crossfile.meson at the root of the numpy-2.2.3 directory in the tar-ball. It get passed using --cross-file= argument. You will find something such as:

c_link_args = [
        '-L/home/spksrc/wheel-meson2/spksrc/toolchain/syno-aarch64-7.1/work/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/lib',
        '-L/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib',
        '-Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/install/var/packages/python312-wheels/target/lib',
        '-Wl,--rpath,/var/packages/python312-wheels/target/lib',
        '-L/home/spksrc/wheel-meson2/spksrc/spk/python312/work-aarch64-7.1/install/var/packages/python312/target/lib',
        '-Wl,--rpath-link,/home/spksrc/wheel-meson2/spksrc/spk/python312/work-aarch64-7.1/install/var/packages/python312/target/lib',
        '-Wl,--rpath,/var/packages/python312/target/lib',
        ]

Also, I was able to pass along -v to numpy (from meson-python documentation: https://mesonbuild.com/meson-python/reference/config-settings.html).

Here's the log output for numpy + scipy that I just recompiled wich shown much more detailed output.
build-aarch64-7.1.log.txt

[th0ma7]

And here's numpy.meson (re-read your post, indeed forgot to provide). It only contains the following:

[properties]
needs_exe_wrapper = false
longdouble_format = 'IEEE_DOUBLE_LE'

[th0ma7]

Similarly, here's scipy.meson:

[properties]
numpy-include-dir = '/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/crossenv-scipy/cross/lib/python3.12/site-packages/numpy/_core/include'
pythran-include-dir = '/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/crossenv-scipy/build/lib/python3.12/site-packages/pythran'
build-python-path = '/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/crossenv-scipy/bin/build-python'
build-python-version = '3.12'
host-python-path = '/home/spksrc/wheel-meson2/spksrc/spk/python312-wheels/work-aarch64-7.1/crossenv-scipy/bin/cross-python'
host-python-version = '3.12'

[th0ma7]

Anything else I can provide to help? And/or should this re-converted as issue or is that simply a misuse from my part? Much thnx in advance.