Re: _Inline directory

Deri wrote:
> It looks like Inline handles this for me. I took my _Inline directory from 
> x86_64 and installed it on an aarch64 pi. (Simulating a nfs shared directory 
> across two machines):-
> 
> ========================================================
> dietpi@tvhnew:~ $ tree _Inline
> _Inline
> ├── build
> ├── config-x86_64-linux-thread-multi-5.032001
> ├── config-x86_64-linux-thread-multi-5.036000
> └── lib
>     └── auto
>         ├── gropdf_1c9b
>         │   ├── gropdf_1c9b.inl
>         │   └── gropdf_1c9b.so
>         ├── gropdf_1c9bf
>         │   ├── gropdf_1c9bf.inl
>         │   └── gropdf_1c9bf.so
>         ├── gropdf_20250619_1c9b
>         │   ├── gropdf_20250619_1c9b.inl
>         │   └── gropdf_20250619_1c9b.so
>         └── gropdf_dj_1c9b
>             ├── gropdf_dj_1c9b.inl
>             └── gropdf_dj_1c9b.so
> dietpi@tvhnew:~ $ echo "Hello"|groff -T pdf > t.pdf
> dietpi@tvhnew:~ $ tree _Inline
> _Inline
> ├── build
> ├── config-aarch64-linux-gnu-thread-multi-5.040001
> ├── config-x86_64-linux-thread-multi-5.032001
> ├── config-x86_64-linux-thread-multi-5.036000
> └── lib
>     └── auto
>         ├── gropdf_1c9b
>         │   ├── gropdf_1c9b.inl
>         │   └── gropdf_1c9b.so
>         ├── gropdf_1c9bf
>         │   ├── gropdf_1c9bf.inl
>         │   └── gropdf_1c9bf.so
>         ├── gropdf_1c9bff
>         │   ├── gropdf_1c9bff.inl
>         │   └── gropdf_1c9bff.so
>         ├── gropdf_20250619_1c9b
>         │   ├── gropdf_20250619_1c9b.inl
>         │   └── gropdf_20250619_1c9b.so
>         └── gropdf_dj_1c9b
>             ├── gropdf_dj_1c9b.inl
>             └── gropdf_dj_1c9b.so
> 
> 9 directories, 13 files
> ===================================================

Well, the config file is new and its file name avoided a collision.

But the .so file is architecture dependent:
$ file _Inline/lib/auto/gropdf_1c9b/gropdf_1c9b.so
_Inline/lib/auto/gropdf_1c9b/gropdf_1c9b.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=15e061d07b4a8a9185ae3111c567c324f589752d, with debug_info, not stripped

In my copy there is also a _Inline/.lock file. Does this lock adequately
protect against concurrent uses from different machines? (Maybe the source
code of libinline-c-perl and libinline-perl tells it?)

Bruno