On 3/13/18 5:19 AM, Alexander Kanavin wrote: > On 03/12/2018 09:48 PM, Mark Hatle wrote: >> Then an advanced user to select a specific version of the 'alternatives'. >> The >> key with all of this is that it needs to be 'reasonable' for both the recipe >> maintainer and the end user. Having to manually rename things, use the >> existing >> update-alternatives, etc really isn't a good idea -- even if it solves (some >> of) >> the user issues.
Back online after a business trip. > But what is the specific need for having both 32 and 64 bit development > packages *installed at the same time*? You do need to explain this, > because any solution will add complexity and headaches for oe-core > maintainers, and multilib is already far too complex and tricky. Two user-cases. The primary one is SDK generation. Right now creating a multilib SDK is causing tons of failures for both headers and executables. The user is trying to build ONE SDK that can build either 32-bit or 64-bit applications and they are getting numerous failures during SDK creation. We've offered the workaround of two SDKs, but needless to say that is far from ideal. The secondary use-case is on-target generation. We're not talking about tiny embedded systems here. We're talking about targets that have 192 or more cores that are used for both executing code, as well as creating customized code alternatives. (Think high-end routers, industrial control systems, etc.) In this case, the biggest issue has been python. The user has a library, which for some reason is available in either 32-bit or 64-bit mode (and ONLY that mode). They don't have the source for that.. so they need to create a program that runs on 32-bit python -- or 64-bit python to use the special library for the processing that they are doing. This is unfortunately still very common. The answer of 'just uninstall' one or the other doesn't solve that problem, as they are both needed to create a functioning system. A related case, it's really the same just different symptoms, is that we have customers who are still needing to run -16-bit- IA code. Yes, you can run 16-bit IA code on Linux -- the key is that it runs in a 32-bit context. So now you are forced to run both a 32-bit and 64-bit user space. 32-bit for legacy (16-bit) code, and 64-bit for any new code. The immediate question is, well then why are you shipping 'development' components for 32-bit, the customer isn't in this case.. but once they enable 'dev-pkgs' in the image gen code, both 32-bit AND 64-bit get dev-pkgs and their system falls apart. In this version of the case, you can't "just uninstall", but you instead now have to convince the system to only install 64-bit dev components, but not 32-bit.. And there is no 'easy' way to do that in the current infrastructure. > If the customer is fine with switching between the two sets, then this > can be trivially solved using existing tools: > > 1. Deinstall 32 bit dev packages on device. > 2. Install matching 64 bit dev packages on device > > ... or vice versa. Just wrap it in a script. Switching really is not an option. Update-alternatives work, but it's too complicated and not exactly 'automatic'. We don't want to have recipe maintainers try to understand the complexities of update-alternative priorities and such. There is also no guaranty that the selected script and ELF executable [or matching library]) is of the matching type. So while it's A solution -- it's not the right one. Instead what I want is a simple equivalent to multilib_header that will also handle abstracting executables with an appropriate wrapper that determines the default behavior based on the users configuration. It's pretty easy to determine what the default for the system is. (i.e. Inspect the related app, is it 64-bit or 32-bit? Check the CC/gcc and it's default word size... etc.) If the system really can't tell you, then the wrapper should stop with an error telling the user it can't determine what the default is and suggest how to pass the value for make/configure/etc. I want a multilib_exec that can be used to generate a wrapper. The recipe will have to pass in the name of what is being wrapped, and how to determine the correct 'default'. The scripting should handle everything else. Like multilib_header it needs to generate an identical script no matter when multilib it's called with, avoiding any potential file conflict during install -- and then an automatic rename of the underlying 'executable'... using the same logic as multilib_header. --Mark > > Alex > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
