All,
I would like to be pointed to a documentation link for how to "properly package" a C++ cross platform library for multi-arch? Specifically, what is the "proper tree?"
![Image]()
When working on 64-bit x86 we have lib/x86_64-linux-gnu. When adding Arm 8 support one will have lib/armv8-linux-gnu. That's all well and good for object libraries. I ass-u-me we should park cmake and pkgconfig directories under the architecture specific library directories, not directly under lib as many other Linux environments do, correct?
Here is the kicker, or at least where my brain has spasmed. What about include files? In a world of cross compiling sans Docker (the real reason we have architecture specific library directories) it is possible the include files could differ based on architecture. Even if they aren't, when user installs MyPackagex86_64-dev.deb then follows it up with MyPackageArmV8-dev.deb (whether that is automatic in repo or manual) there will be two deb packages installed that can both lay legitimate claim to "owning" /usr/include/MyPackage/*. What happens when user un-installs ArmV8? Is the packaging system on Debian keeping reference counting just how many other Debian packages have installed those same files so it doesn't nuke them?
I spent the past decade of my nearly 40 year IT career working in the embedded systems (mostly medical device) world and I can tell you it is nothing to need to cross compile for up to 3 different processor types in any given project. Sadly I don't have any of the pre-Docker build world client machines around to determine just how the include files for each library were handled, so I must ask. I would like the package I'm working on to function perfectly in a non-Docker cross compiling medical device universe.
Thanks for whatever official documentation links get provided. I did some poking around and did not find what I needed/wanted/comprehended.
I would like to be pointed to a documentation link for how to "properly package" a C++ cross platform library for multi-arch? Specifically, what is the "proper tree?"
When working on 64-bit x86 we have lib/x86_64-linux-gnu. When adding Arm 8 support one will have lib/armv8-linux-gnu. That's all well and good for object libraries. I ass-u-me we should park cmake and pkgconfig directories under the architecture specific library directories, not directly under lib as many other Linux environments do, correct?
Here is the kicker, or at least where my brain has spasmed. What about include files? In a world of cross compiling sans Docker (the real reason we have architecture specific library directories) it is possible the include files could differ based on architecture. Even if they aren't, when user installs MyPackagex86_64-dev.deb then follows it up with MyPackageArmV8-dev.deb (whether that is automatic in repo or manual) there will be two deb packages installed that can both lay legitimate claim to "owning" /usr/include/MyPackage/*. What happens when user un-installs ArmV8? Is the packaging system on Debian keeping reference counting just how many other Debian packages have installed those same files so it doesn't nuke them?
I spent the past decade of my nearly 40 year IT career working in the embedded systems (mostly medical device) world and I can tell you it is nothing to need to cross compile for up to 3 different processor types in any given project. Sadly I don't have any of the pre-Docker build world client machines around to determine just how the include files for each library were handled, so I must ask. I would like the package I'm working on to function perfectly in a non-Docker cross compiling medical device universe.
Thanks for whatever official documentation links get provided. I did some poking around and did not find what I needed/wanted/comprehended.
Statistics: Posted by seasoned_geek — 2024-09-13 20:35 — Replies 1 — Views 21