inconsistent installed path for C# .dll across platforms

summary.md

What I tried

In pkgsrc (a cross-platform Unix package system), I've created a package of Xapian (a search engine) and a package of its C# bindings.

Each package has a packing list (PLIST) that specifies exactly which files are part of it. If a given source build would generate a binary package that doesn't contain both everything in the PLIST and nothing not in the PLIST, that build fails.

I developed these packages on Mac OS and also tested them on NetBSD. The PLIST I came up with on my Mac needed no changes for NetBSD. Both systems agree that version 1.4.4 of the C# bindings had better place a .dll in these two places (relative to the package system's install prefix):

lib/mono/XapianSharp/XapianSharp.dll

lib/mono/gac/XapianSharp/1.4.4.0__7d35319790c0921d/XapianSharp.dll

So I committed the C# bindings to pkgsrc.

Fresh logs from a happy build on a Mac:

• make configure
• make build
• make install

What I expected

I figured I did a pretty decent job, and the Xapian C# bindings would probably build on any pkgsrc-supported platform that can build Mono and Xapian itself (written in C++11).

I'm aware of only one pkgsrc-supported platform that simultaneously

• Can build Mono and Xapian
• Has regular bulk builds to exercise every package
• Doesn't agree with my PLIST above

(There may be others, but I'm not aware of any.)

What happened instead

Fresh logs from an unhappy build on SmartOS (an Illumos derivative), using the same Mono and Xapian as dependencies:

• make configure
• make build
• make install

What I'd like to understand

Where does the .dll on Mac/NetBSD/presumably-others figure out that 7d35319790c0921d, in particular, is what needs to be baked into its install path? Because Illumos wants it to be 0bc103bf9c9cfedd instead.

How could I influence any given build to pick a different value for that? I bet this knowledge would be enough for me to force a consistent installed path across pkgsrc platforms.