Anyone Look Into Wine?

[Hooovahh]

Oh that is a shame about the 32 bit OS libraries.  I was just hoping that I could use the 64 bit ones with multiarch but it sorta makes sense that it isn't the case.  Maybe I'll look into it a bit further using a VM'ed Linux machine to get a better idea of what libraries are needed.  Otherwise it might be a long journey. 

I haven't went through the process of installing it yet, but it looks like xvfb could be used to more or less emulate a display, and allow for running programs that have a command line interface, but still call into window functions, on controllers without an embedded display.

My cDAQ actually has an Embedded Windows option, but we wanted the determinism.  As mentioned earlier, putting wine on a Linux RT is optional.  For me I can connect a Windows PC on a network, and have it run the 32 bit binary, but I made it this far and learned so much.  Figured I should just keep trying things and hope that I can get a full solution for the community.

[Alejandro_del_Castillo]

I tried recreating these packages with the gzip compression so updating opkg wouldn't be necessary, but some of these had errors when reading the header text, with the newest stable release of opkg.  Also some times I would get Segmentation Faults and I would just uncompress, then recompress with gzip and it would work fine.

mm, that's concerning, at the very least it should error out and not segfault. If you have a package that conforms to the deb format (compressed with gzip) that is segfaulting, do you mind opening a bug report for opkg on https://bugzilla.yoctoproject.org/? (You'll need to create a bugzilla account if you don't have one).

I am maintaining the project, so I am interested in making sure deb packages can be consumed by opkg.

[Hooovahh]

I'd guess that 90% of the debian packages I download I need to still extract and recompress to get opkg to install them.  I just downloaded and compiled the newest opkg source from the commit that was 90 minutes ago.  After installing multiarch-support, I attempt to install libmpg123-0 package and it will return Segmentation fault.  I perform the following operations (on a Debian VM) to extract the package, extract the xz, recreate the gz, and recreate the package.  After that the Rebuilt package will install.

ar vx ./Download_libmpg123-0_1.20.1-2_amd64

tar xf data.tar.xz will extract the xz

tar -cvzf data.tar.gz ./usr will create the gz

ar rcv Rebuilt_libmpg123-0_1.20.1-2_amd64.deb debian-binary control.tar.gz data.tar.gz

I do have a follow up question.  Is OPKG multiarch-aware?  By that I mean can I even install the same package for two different architectures at once?  Looking at a seperate Debian VM I can see what packages are needed to install wine64 and wine32, and as you mentioned many of the ones installed for wine32 are system packages, because these aren't install with the 64 bit OS by default.  I've tried to install some of these for i386 and it claims the package is installed and up to date.  Also when I perform an opkg list-installed it only shows one version.  Is there any thing special I need to know, about trying to install the same package, for multiple architectures at once?  Thanks again.

[BradM]

Brian Hoover wrote:

...

I do have a follow up question.  Is OPKG multiarch-aware?  By that I mean can I even install the same package for two different architectures at once?  Looking at a seperate Debian VM I can see what packages are needed to install wine64 and wine32, and as you mentioned many of the ones installed for wine32 are system packages, because these aren't install with the 64 bit OS by default.  I've tried to install some of these for i386 and it claims the package is installed and up to date.  Also when I perform an opkg list-installed it only shows one version.  Is there any thing special I need to know, about trying to install the same package, for multiple architectures at once?  Thanks again.

OPKG is multiarch-aware in a fairly simple, dumb, but configurable manner: the /etc/opkg/arch.conf file controls what architectures can be installed on the system (along with prios), but it does not have the means to understand that package foo, for arch x86, depends on bar and the x64 bar that is already installed is unusable (since bar is a library, it has an actual architecture).

Some distros' package managers are also subject to this issue and work around it by means of system library packagename prefixing (to let you know that, for example, you're dealing with a 32-bit x86 library package installation). There are some resources on how to make this sort of thing possible on OE-based distros here: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-libr...

[Hooovahh]

Thanks for that information, and I'm aware that opkg allows you to install packages from multiple architectures, but what I'm asking about is installing the same package for multiple architectures at the same time.

If I install gcc-4.9-base_4.9.2-10 for amd64, and then choose to install gcc-4.9-base_4.9.2-10 for i386 it appears to install one, then the other just fine.  And if I perform list-installed it shows one entry for gcc-4.9-base version 4.9.2.  But if I have package libc6 version 2.21-r0.239 installed for amd64 (the one provided by NI), and I then choose to install libc6 version 2.19-18 for i386, it won't allow it because it claims it will break dependencies by downgrading, and it would if I were downgrading the amd64 version.  But even if it did install the 2.19 i386 version, would it uninstall the 2.21 amd64 version?  Would there still be only one entry in list-installed?  At the moment when I look at the packages installed I don't see a way to determine what architecture a package is installed for.

What I think is true (but can't confirm on the internet) is that you can only install a package for multiple architectures, if it is the exact same version for those architectures.  Which would mean for me to install libc6 for i386 I'd need to get a hold of the source NI used, so I could build it for i386.  And then repeat that for many system level packages.

[BradM]

The resources that I pointed out was intended to show that you need to make more fundamental changes to how the image is built (certainly for the feed creation, possibly even more fundamentally during image creation time). The fact of the matter is that opkg does not cleanly or clearly differentiate the actual architecture aspect of installed packages (what happens with some distro's handling of multi-arch installation) is not present with opkg, as you're finding.

The way that this is handled in such cases is to differentiate the package naming to call-out that the package handles an architecture other than what the base system architecture is (e.g. glibc6 vs. lib32-glibc6).

[Hooovahh]

Thanks again.  I made a document posted here, which describes in a cleaned up form how to get Wine64 installed, and the process to do it yourself if my method doesn't work.  I've got a solution that I think will work in my case and I'm leaving it up to others to hopefully get other things working like Wine32, and Xvfb for terminal programs that call into Windows UI API calls.

[metux]

Multiarch setups are always tricky to manage (beginning w/ proper toolchain and libc setup). Most distros only provide a few compat libraries.

Why aren't you just setting up a chroot/container ?

Or compile WinE on your own ?

Yes, setting up a proper build system for cRIO targets isn't entirely trivial (especially when it comes to packaging, repo management, ...). Needs some extra prerequisites and helpers. Would be nice to have that done fully automatically:

https://forums.ni.com/t5/Additional-NI-Software-Idea/cRIO-image-development-kit/idc-p/3820247