mcorino / wxRuby3

Ruby Cross-Platform GUI extension
https://mcorino.github.io/wxRuby3/
MIT License
83 stars 6 forks source link

Problem with wxruby setup --wxwin=path building on Windows 11 #275

Closed Randalphwa closed 5 months ago

Randalphwa commented 6 months ago

Build method used

I am trying to build wxRuby3 with wxruby setup following directions in INSTALL.md

Build options used

Directions suggest running:

wxruby setup --with-wxhead

which results in:

invalid option: --with-wxhead
Did you mean?  with-wxwin

That appears to be a doc problem about the -- prefix? Leastwise leaving off the -- caused different problems, similar to what's reported below.

Description

The real problem I'm having is trying to build on Windows using:

wxruby setup --wxwin=D:\github\wxWidgets

which results in:

bash.exe: warning: could not find /tmp, please create!
bash.exe: warning: could not find /tmp, please create!
bash.exe: warning: could not find /tmp, please create!
ERROR: Cannot find wxWidgets. wxRuby requires a wxWidgets >= 3.2.0 release.

And before you ask , yes there is a D:/tmp, yes I installed RubyInstaller MSYS2-Devkit, and yes that version of wxWidgets is current -- and I also tried on my fork of wxWidgets which fails the same way. Oh, and yes wxRuby3 0.9.4 ran fine on Windows 11 -- I just need a more current wxRuby3 release, preferably running my wxWidgets fork.

I am running from a cmd.exe shell since INSTALL didn't indicate if I should be running some other shell. Should I be running a different shell even though I'm trying to build for Windows?

Platform and version information

mcorino commented 6 months ago

First off; you most likely read the INSTALL.md document of the 'master' branch where you are currently most likely using the v0.9.8 gem. If you check the INSTALL.md document at the 'v0.9.8' tag in the github repo (or here) you will notice that the '--with-wxhead' option did not exist yet for that version.

Second; the "Did you mean? with-wxwin" notification does not come from my code but most likely from the standard Ruby 'optparse' module. No idea why that does not mention the '--' prefix but as per commonly accepted standard all accepted 'long' switches are always prefixed with '--'.

Thirdly, the real problem; this is most likely due to path separator issues. Please try specifying 'D:/github/wxWidgets'. I will revisit this code and work a solution to accept either format. Using the standard cmd.exe shell is fine.

mcorino commented 6 months ago

BTW, please be advised wxRuby3 has never been tested on Windows 11 and judging by other reports there may well be some issues on that platform. I do not have Windows 11 available myself and have not yet found any Windows 11 CI platforms. I also do not believe wxWidgets itself is regularly tested on Windows 11 (and also has issues reported).

Randalphwa commented 6 months ago

I had already tried changing to forward slashes, but have the same problem. Ruby+DevKit ignored the fact that I already had installed MSYS2, and created it's own version. I uninstalled my original MSYS2 installation, but that didn't help either.

mcorino commented 6 months ago

Hmmm, ok, I will run some tests and see what happens.

Randalphwa commented 6 months ago

Looks like user error. I assumed that since Install told me to install ruby+devkit then the --wxwin would actually use msys2 to build wxWidgets. What it does not mention is that I need a MSYS2 installation, and then I need to build wxWidgets using that toolset. You only need to download the devkit option if you don't have a MSYS2 installation -- because if you already do, then you will end up with a second copy of it. Or at least I assume it would work with a separate installation of MSYS2...

mcorino commented 6 months ago

Ok, that explains why I cannot reproduce your problem on my Windows system. I had assumed that anyone brave enough to attempt building against a user installed wxWidgets installation on Windows would be well versed in the requirements to build Ruby native extensions on Windows. But thanks for bringing this to my attention. I think I will extend the docs in this area a little with some extra info on the requirements for Windows. I do not think though that what matters is the MSYS2 installation (which is essentially a *nix-like toolset for Windows) but rather the MingW64 compiler suite that is installed. That one MUST match the one with which Ruby (and it's standard native extensions) itself is built. Combining a RubyInstaller installation without devkit with a user installed MSYS2 set and MingW64 set brings with it the real danger of installing the a mismatched version which will cause problems. This is why I did not (and will not) describe this as an option. Instead I will probably add a note telling NOT to do this.

Randalphwa commented 6 months ago

I build multiple versions of wxWidgets for C++ on both Windows and Linux, so I just foolishly thought "How hard can it be?". 😬 Still, if I have to supply a binary build of wxWidgets anyway, I might as well learn how to build one that works with wxRuby3.

mcorino commented 6 months ago

Are you all set now? Can I close this issue? Please note that wxWidgets 3.2.5 should be released May 14 and I expect to release wxRuby3 1.0.0 (including several additions/improvements and bugfixes) shortly following that.

Randalphwa commented 6 months ago

All set in knowing where to find more information for building wxWidgets using MingW64 -- I'll reopen if I run into further problems.

Randalphwa commented 5 months ago

In my latest saga of trying to get wxRuby running on a Windows 11 machine, I tried downloading wxruby3_windows_ruby33-1.0.0-x64-mingw-ucrt.pkg, wxruby3_windows_ruby33-1.0.0-x64-mingw-ucrt.sha, wxruby3-1.0.0.gem, and wxruby3-1.0.0.gem.asc from the v1.0.0 assests. I then ran:

gem install --local wxruby3-1.0.0.gem -- package=D:\Ruby32-x64\wxruby3_windows_ruby33-1.0.0-x64-mingw-ucrt.pkg

I then ran wxruby check and got the following output:

The runtime environment of this system seems to be missing some required libraries for
executing wxRuby3 apps.
Please be aware wxRuby3 requires a properly configured GUI based system to function.
See the documentation for more information on the required runtime environment.

Checking \Ruby32-x64\lib\ruby\gems\3.2.0\gems\wxruby3-1.0.0\ext I see:

 5/19/2024  14:50       4,373,600  wxbase32u_gcc_custom.dll
 5/19/2024  14:50         897,136  wxbase32u_net_gcc_custom.dll
 5/19/2024  14:50         199,434  wxbase32u_xml_gcc_custom.dll
 5/19/2024  14:50       1,134,201  wxmsw32u_aui_gcc_custom.dll
 5/19/2024  14:50      15,052,683  wxmsw32u_core_gcc_custom.dll
 5/19/2024  14:50         322,866  wxmsw32u_gl_gcc_custom.dll
 5/19/2024  14:50       1,739,424  wxmsw32u_html_gcc_custom.dll
 5/19/2024  14:50         356,602  wxmsw32u_media_gcc_custom.dll
 5/19/2024  14:50       1,830,781  wxmsw32u_propgrid_gcc_custom.dll
 5/19/2024  14:50         427,294  wxmsw32u_qa_gcc_custom.dll
 5/19/2024  14:50         722,070  wxmsw32u_ribbon_gcc_custom.dll
 5/19/2024  14:50       2,980,446  wxmsw32u_richtext_gcc_custom.dll
 5/19/2024  14:50       3,793,974  wxmsw32u_stc_gcc_custom.dll
 5/19/2024  14:50         666,901  wxmsw32u_webview_gcc_custom.dll
 5/19/2024  14:50       2,000,217  wxmsw32u_xrc_gcc_custom.dll

So it would appear that the dll's did indeed get installed. I tried the obvious of adding the full path to these dlls to $PATH but that didn't work either. I already tried downloading the wxWidgets msys 3.2.5 binaries and using wxruby setup --wxwin to point to them, but that didn't work either (this was prior to trying to install the .pkg file). Anyways, I realize your install documents indicate there is no Windows distribution, so using the windows .pkg files is not officially supported, but it sure seemed like it would be the easiest way to get a working version of wxRuby3 on Windows. Any suggestions on what I might try next for a prebuilt binary?

I just found out that gem install wxRuby3 on fedora 39 also doesn't install the wxWidgets files, so I've got the same problem there...

mcorino commented 5 months ago

Sorry, I missed your update as the issue did not get re-opened.

First your last remark regarding fedora 39. I cannot reproduce that. I have quickly tested with both the system default Ruby 3.2.4 and an RVM installed Ruby 3.3.1. Both work without a hitch. Have you tried wxruby check -v to get more information on what may be going on?

As far as Windows 11 is concerned you could also try wxruby check -v after installing the binary package to see if that gives some more information.

Unfortunately for the rest I will have to repeat what I said earlier; I do not have access to any Windows 11 environment at the moment (which will probably remain so for quite a while as long as MS maintains the ridiculous hardware requirements as I absolutely refuse to buy new hardware to install an OS that I habitually try to avoid) and as long as that remains the case I'm pretty much in the dark on this one.

Randalphwa commented 5 months ago

On fedora 39 with Ruby 3.2.4: gem install wxruby3

Building native extensions. This could take a while...

The wxRuby3 Gem has been successfully installed including the 'wxruby' utility.

followed by a bunch of information about ensuring it is setup correctly, and then:

Successfully installed wxruby3-1.0.0
Parsing documentation for wxruby3-1.0.0
Done installing documentation for wxruby3 after 0 seconds
1 gem installed

Now when I run wxruby check -v I get:

Checking build (or binary package installation) completion...

wxRuby3 requires the post-install setup cmd to be run to build and finish installing
the required runtime binaries. Execute the command like:

$ wxruby setup

To see the available options for the command execute:

$ wxruby setup -h

I have not had a chance yet to try installing on a Windows 10 system. It's on my list to swap some monitors around so that I can check this on a Ubuntu 22 system, where I assume/hope it will work fine.

I'm going to re-open this issue for now both to update what I find, and also in case someone else runs into similar problems and/or finds a solution.

mcorino commented 5 months ago

As said I cannot reproduce your problems on a (virgin) fedora 39 system (Vagrant box). When I run gem install wxruby3 with the system Ruby (3.2.4) there it just installs the binary package as it should. In your case it seems it does not. About the only things I can think of right now are platform characteristics or network access problems somehow. What does uname -a' say on this system? Is this system capable of downloading the binary package like thiswget https://github.com/mcorino/wxRuby3/releases/download/v1.0.0/wxruby3_fedora_39_ruby32-1.0.0-x86_64-linux.pkg`?

mcorino commented 5 months ago

BTW regarding this remark from you above:

Anyways, I realize your install documents indicate there is no Windows distribution, so using the windows .pkg files is not officially supported

I'm wondering where you read that. Afaict the INSTALL document states clearly that a binary package for Window x86_64 for the latest stable Ruby is definitely supported (and the README states that this is tested on Windows 10 only). I also have the CI build results to prove it ;-)

Randalphwa commented 5 months ago

In the table of standard packages in INSTALL.md where it lists the OS and distributions, Windows has N/A for distribution. Since gem install stopped working on Windows 11 after 0.94 and after reading this table, I just assumed the build process changed in some way so that Windows now required setting up the wxWidgets dlls separately. It seems odd that a change in Windows 11 would affect this, but I'll check on my Windows 10 computer to verify.

My Fedora is running on WSL, so there must be some issue with that custom distribution that is causing the package to fail. Probably doesn't make sense to run any ruby program on a WSL installation when it should run just as well directly from Windows, so this probably not an issue for most folks. It just affects me because I lost the ability to install it on Windows 11, and I need some working version to verify that code generation for wxRuby3 is working correctly.

Randalphwa commented 5 months ago

Just tried on my Windows 10 machine and it doesn't install there either. I entered gem install wxruby3 and got:

Fetching wxruby3-1.0.0.gem
Temporarily enhancing PATH for MSYS/MINGW...
Building native extensions. This could take a while...

The wxRuby3 Gem has been successfully installed including the 'wxruby' utility.
``

followed by the usual messages about how to run wxruby and then:

Successfully installed wxruby3-1.0.0 Parsing documentation for wxruby3-1.0.0 Installing ri documentation for wxruby3-1.0.0 Done installing documentation for wxruby3 after 3 seconds 1 gem installed


`wxruby check` reports:

wxRuby3 requires the post-install setup cmd to be run to build and finish installing the required runtime binaries. Execute the command like:

$ wxruby setup


Running `wxruby setup` results in:

Now running wxRuby3 post-install setup. This will (possibly) install required software, build the wxWidgets libraries (if needed), build the native wxRuby3 extensions and generate the wxRuby3 reference documentation. Please be patient as this may take quite a while depending on your system.

ERROR: Cannot find wxWidgets. wxRuby requires a wxWidgets >= 3.2.0 release.


I do notice one difference when running `gem install wxruby3 -v 0.9.4`:

Successfully installed wxruby3-0.9.4-x64-mingw-ucrt



That line does not appear when install 1.0.0

A bit of a long shot, but I did try uninstalling Ruby and re-installing to get a clean slate. It still didn't work.
mcorino commented 5 months ago

I was about to answer that I did not know what to tell you as testing on my regular Windows machine again did not show any problems.

However I decided to run additional tests on a clean Windows VM just to be sure and lo and behold I ran into a problem.

Not the problem though you report for Windows 10 mind you but the problem you reported earlier for Windows 11.

Your problem on Windows 10 looks more like the problem you reported for Ubuntu: not getting a binary package installed. This would typically happen if the gem setup scripts cannot find/access a package matching the platform either due to network problems or mismatched platform characteristics (Ruby version and/or OS). In your Windows 10 case you might check if you have a Ruby version installed for which a binary package is available (currently only Ruby 3.3). But just wait a bit because the problem I found has repercussions for that.

What I found was that on my Windows 10 VM the gem did install the binary package but I ran into runtime problems after that similar to what you reported for Windows 11. I found that the difference was that on my regular machine I had Ruby 3.3.0 installed and on the VM I just installed the latest 3.3 which was 3.3.1 (which is supposed to be ABI compatible to 3.3.0). As the release build, as fas as I could recall, had used 3.3.0 to build the binary package I began to suspect a rat here and removed 3.3.1 on my VM and installed 3.3.0. And ... of course everything worked fine after that :sob: .

So it seems there is an ABI incompatibility in RubyInstaller Ruby 3.3.1 compared to 3.3.0 and you will have to install 3.3.0 to be able to use the prebuilt binary package.

This may also explain the Windows 11 problems you have been having. And I myself as well as in the meantime I have been able to install Windows 11 on some older hardware with the help of some clear instructions I found online on how to circumvent the idiotic requirements of MS. I can already report that I have just been able to successfully run wxruby setup --with-wxwin with Ruby 3.3.1 and run successful tests with wxruby test. Next I will install Ruby 3.3.0 and see if that will install and run the release package without building.

mcorino commented 5 months ago

Ok, that's it.

After installing RubyInstaller 3.3.0-1 on Windows 11 I could successfully install the wxruby3 including the downloaded binary release package and run the tests and the sampler app without problems. I'm going to check with the RubyInstaller people why their 3.3.1 release is not ABI compatible with 3.3.0 like it is on other platforms.

Randalphwa commented 5 months ago

That would certainly explain why all versions through 0.9.4 installed and ran just fine.

It might also explain the problem I was just about to report which is that I got my Ubuntu 22 machine running again, used sudo to do a ruby-full install (which installed ruby 3.0.2) and the gem install wxruby3 -- and wxruby check failed, saying I needed to run wxruby setup.

I'll try changing the installer version later today and let you know the results on my end...

Just checked, gem on Ubuntu 22 machine is 3.3.5, on Windows it is 3.5.5

mcorino commented 5 months ago

Just checked, gem on Ubuntu 22 machine is 3.3.5, on Windows it is 3.5.5

Yes, these versions widely differ depending on the version of the Ruby package installed but that has no influence. It's only the Ruby version itself (ruby -v).

Randalphwa commented 5 months ago

I apologize if I'm being dense here -- I think I got spoiled when up through 0.9.4 I could just do a gem install wxruby3 and nothing further was needed. That actually still works if I install ruby 3.2.2 and use gem install wxruby3 -v 0.9.4. I did try updating my Windows 11 ruby to ruby_devkit 3.3.1-1 and then trying gem install wxruby3 which still didn't get me a working version. However, that also prevented getting the 0.9.4 to work and I panicked and uninstalled ruby entirely and went back to ruby 3.2.2 where 0.9.4 installs and runs.

My WSL fedora 39 has ruby 3.2.4. The straight gem install wxruby3 doesn't work. I tried downloading the .gem and .asc files along with wxruby3_fedora_39_ruby32-1.0.0-x86_64-linux.pkg and wxruby3_fedora_39_ruby32-1.0.0-x86_64-linux.sha and then using gem install --local ./wxruby3-1.0.0.gem -- that still doesn't install the wxWidgets binaries.

I have a separate machine with Zorin OS on it which is based on Ubuntu 22.04 and has ruby 3.0.2. gem install wxruby3 doesn't install the binaries, so I tried downloading .gem, .asc, wxruby3_ubuntu_22.04_ruby30-1.0.0-x86_64-linux.pkg and wxruby3_ubuntu_22.04_ruby30-1.0.0-x86_64-linux.sha and running gem install --local ./wxruby3-1.0.0.gem but that also doesn't install the binaries.

In the good news department, I did fire up a Virtual fedora 39 Box on my Ubuntu machine, installed ruby (3.2.4) ran gem install wxruby3 and tried wxruby check which didn't report anything. wxruby sampler worked like a charm, so it did correctly install. While it's far from ideal, I at least now have a way to verify that changes to my RAD tool that can generate wxRuby3 code works correctly. Whew! I must say it's really weird that fedora+wxRuby3 runs on a Virtual Box under Ubuntu but not on WSL. I wish I knew what was different -- even I could just get the binaries installed from the .pkg files it would give me a working wxRuby3.

mcorino commented 5 months ago

First off, there are only a select number of binary release packages available. Each for a particular combination of OS (version), CPU type and Ruby version. You can see the list here. The gem installation script (the gem is configured as building a native extension which makes the script run) will check based on the Ruby version it is run from combined with platform characteristics (OS + CPU type) if a binary release package is available. If no matching package can be found (or fails to download, not likely but possible) the gem reverts to source only install and wxruby check will report the binaries need to be built.

For checking the platform characteristics the scripts rely on standards. I'm not sure WSL installations comply with all these standards so it may be nay to impossible to get a binary package match there (and that may also affect building as the same standards are used to match setup of requirements and build setup etc.). You can try to get it running on WSL but you are pretty much on your own there. I will not spend much time of that effort but will review patches if offered.

As far as Windows is concerned I think you may have misunderstood my latest comments. Installing Ruby 3.3.1-1 will NOT get you a working binary installation. You need to install the 3.3.0-1 version as the binary release package for Windows was built with that version and it seems the 3.3.1-1 version is not ABI compatible.

Randalphwa commented 5 months ago

I could have sworn I tried the 3.3.0/gem install, but I spent so many hours trying to get it installed on anything that I lost track. Anyways, did an uninstall, deleted the entire directory which uninstall doesn't remove, and reinstalled the 3.3.0-1 from the archives, did the gem install wxruby3 and it works! 👍

I can't image anyone besides me caring about running a ruby program on WSL -- or at least it would be extremely rare. I only cared because I couldn't get it installed on Windows. I already know you are testing controls on Linux, so I figure if the UI controls I'm generating code for are working on Windows 11 then I don't need more than a cursory check on Linux. Switching to my Unix computer instead of running a WSL version is not a problem.

Fine with me if you want to close this issue -- with a working version on Windows and on a virtual box version of fedora, I have everything I need -- at least until you release another version. 😁 Hopefully by then, the Ruby team will have fixed the issue of breaking ABI...

mcorino commented 5 months ago

I could have sworn I tried the 3.3.0/gem install, but I spent so many hours trying to get it installed on anything that I lost track.

I have been there. :wink:

Anyways, did an uninstall, deleted the entire directory which uninstall doesn't remove, and reinstalled the 3.3.0-1 from the archives, did the gem install wxruby3 and it works! 👍

Great!

Fine with me if you want to close this issue -- with a working version on Windows and on a virtual box version of fedora, I have everything I need -- at least until you release another version. 😁 Hopefully by then, the Ruby team will have fixed the issue of breaking ABI...

Same here.

mcorino commented 5 months ago

@Randalphwa FYI, I found the cause of the problems with the RubyInstaller 3.3.1-1 release. See my comment here.