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
