For those knowledgeable about WSL2

[Gonzalo Garramuño]

Two issues with WSL2:

1) I started playing with WSL2 on Windows 11 PRO to avoid having to dual
boot to compile my application.  I was able to build my application fine
with WSL2 with a Dockerfile.  It compiled, installed and runs fine under
Linux from a .deb package.  I then tried running it under WSL2, to see
if I could do all testing and development for both OSes without dual
booting, but I got the GLFW error trapping to emit a:

    GLFW Error: GLX: failed to create context: GLXBadFbConfig

I tried compiling under WSL2 the FLTK demos and a GLFW application that
uses the same OpenGL core as my program and both work fine except that
they seem to segfault on exit on WSL2.

Since my application uses both FLTK and GLFW, I still have to debug
what's causing the GLX error (if it is an FLTK, a GLFW or my own
error).  So... We'll hold on on that for now.  And we'll hold on the
segfault also.

2) Now for what I really want to know... I tried going the opposite way
with a build that was compiled on my dual boot system on Ubuntu (not
thru a Dockerfile/.deb install), when I run it under WSL2, I get:

libfltk_gl.so.1.4.so: file too short.

The DSO is not corrupt.  The DSO and application works just fine under
Ubuntu 22.04.3 (I dual boot and read the file from the same local NTFS
disk location).  It chokes under the WSL2 with that cryptic message. 
Maybe someone with more knowledge of WSL2 can explain to me why the DSO
may not work.  I chmod a+rwx the DSO already.

The only thing I noticed is that WSL2 uses Ubuntu 22.04.2 while I have a
native Ubuntu 22.04.3, but surely the DSO format has not changed in between.

--
Gonzalo Garramuño
ggar...@gmail.com

[Matthias Melcher]

I had a brief brush with WSL and later WSL2 when I was using MSWindows for a while.

One common issue seems to be that GLFW can be compiled for either X11 or Wayland, and it must be compiled for the same target as the rest of your app. With FLTK supporting both X11 and Wayland at the same time, I assume that means you have to find out which one your app chooses and link the corresponding GLFW. 

No idea why you get the "file too short" error though, but in general, I try to link all my apps statically. FLTK is small enough and it reduces installation woes. You can check the file type with `file ibfltk_gl.so.1.4.so` and see the content with `nm -D ibfltk_gl.so.1.4.so` or `objdump -T ibfltk_gl.so.1.4.so`. Hope that helps... .

[Gonzalo Garramuño]

El 11/25/2023 a las 8:55 AM, 'Matthias Melcher' via fltk.general escribió:

I had a brief brush with WSL and later WSL2 when I was using MSWindows for a while.

One common issue seems to be that GLFW can be compiled for either X11 or Wayland, and it must be compiled for the same target as the rest of your app. With FLTK supporting both X11 and Wayland at the same time, I assume that means you have to find out which one your app chooses and link the corresponding GLFW. 

GLFW (HEAD) now supports compiling both X11 and Wayland in the same library (either statically or dynamically).  You can then switch at runtime with a glfwInitHint().  In my classes I have it recognize "FLTK_BACKEND" and "XDG_SESSION_TYPE" to select the backend that it uses.

No idea why you get the "file too short" error though, but in general, I try to link all my apps statically. FLTK is small enough and it reduces installation woes. You can check the file type with `file ibfltk_gl.so.1.4.so` and see the content with `nm -D ibfltk_gl.so.1.4.so` or `objdump -T ibfltk_gl.so.1.4.so`. Hope that helps... .

Static linking for my application is not an option as I need to provide swig wrappers and also need to link against FFmpeg libs which for legal reasons I can't link statically.

$ file libfltk_gl.so.1.4.0

libfltk_gl.so.1.4.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e6121db98db515231e28416447a3aa058818ce43, not stripped

$ nm -D libfltk_gl.so.1.4.0 | grep Fl_Widget
00000000000154f0 W _ZN19Fl_Gl_Device_Plugin17rectangle_captureEP9Fl_Widgetiiii
0000000000015450 W _ZN19Fl_Gl_Device_Plugin5printEP9Fl_Widget
                 U _ZN2Fl5focusEP9Fl_Widget
                 U _ZN8Fl_Group3addER9Fl_Widget
                 U _ZN8Fl_Group9on_insertEP9Fl_Widgeti
                 U _ZN9Fl_Widget6damageEh
                 U _ZN9Fl_Widget6redrawEv
                 U _ZNK9Fl_Widget10top_windowEv

$ ldd libfltk_gl.so.1.4.0
./libfltk_gl.so.1.4.0: error while loading shared libraries: libfltk.so.1.4: file too short

Oh... I think I see what the problem is.  libfltk.so.1.4 is a symbolic link, not an actual DSO.  It seems WSL2 has no concept of symlinks from Ubuntu.  I can create *new* symlinks, but not actually *read* symlinks that are already created from Ubuntu.  And the newly created symlinks can also *not* be read by the native Ubuntu on the same NTFS drive.

Oh well... Microsoft *almost* got it right this time, but they still suck.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Ian MacArthur]

FWIW, I've been using WSL2 on Win11 a fair bit, and for the most part it works well - better than my experiences with WSL(1) anyway. 

For those less familiar with the whole WSL business on Windows machines, WSL(1) was a sort of "reverse-Wine" in that it ran Linux code on a "kernel" that was (crudely speaking) a interface layer that mapped Linux kernel calls to the underlying WIN32 API. TBH it mostly worked OK, but there were quite a few "oddities"... On top of this kernel ran a userspace that was "very like" an Ubuntu system, albeit with no easy windowing support as such.

WSL2 instead is a "lightweight" VM that runs a real Linux kernel alongside the WIN32 kernel (rather than on top of it) that runs (in my case at least) a "real" Ubuntu distro., along with windowing and etc. It pretty much Just Works, and the WSL app windows appear alongside the WIn32 app windows and it all hangs together pretty well.

So from my perspective, from the WSL console shell, it looks "exactly" like an Ubuntu distro., albeit with a slightly odd WM. I can add/remove packages with apt as I would normally and so on.

I've only built FLTK (and my various FLTK tools) statically linked on WSL2, but so far it has been entirely normal - just like a regular Ubuntu setup. Both X11 and Wayland seem to work fine, performance is OK. FWIW, I also have a VBox VM running Ubuntu on this same Win11 host, and my _impression_ is that the WSL2 system is more nimble than the VBox VM. I do not have hard metrics to prove that however. The GL and GPU performance in WSL2 is definitely better than the VBox VM however, if that matters, at least on my box. Though not by much.

I have not tried any dynamic linking, so can't comment on that, nor have I tried GLFW, so I have nothing directly pertinent to Gonzalo's queries.

I have copied (statically linked to fltk, but dynamically linked to the systemlibs) apps between this WSL2 setup and a real Ubuntu machine, and that has Just Worked, so this suggests to me that the libs and apps should be portable. The real Ubuntu was from an LTS branch that was essentially "the same" as the WSL2 machine though, so lib versioning probably would not be an issue - it might be with versions that were more dissimilar.

On Saturday, 25 November 2023 at 12:35:30 UTC Gonzalo wrote:

$ ldd libfltk_gl.so.1.4.0

./libfltk_gl.so.1.4.0: error while loading shared libraries: libfltk.so.1.4: file too short

Oh... I think I see what the problem is.  libfltk.so.1.4 is a symbolic link, not an actual DSO.  It seems WSL2 has no concept of symlinks from Ubuntu.  I can create *new* symlinks, but not actually *read* symlinks that are already created from Ubuntu.  And the newly created symlinks can also *not* be read by the native Ubuntu on the same NTFS drive.

Oh well... Microsoft *almost* got it right this time, but they still suck.

I find that if you stay inside the WSL2 filesystem enclave (which is ext3 or ext4 I think, can't remember...) it all works exactly the way you expect.  If you use the WLS2 to access NTFS filesystems, things still work, but it is obvious that it's not a *nix filesystem - e.g. all files are shown as having the executable bit set and so on, permissions go weird generally, I was under the impression that symlinks still worked though (that may be a false memory!) FWIW, NTFS does support symlinks natively, so it should be possible to make this work!

When you cross over between the WSL2 filesystem and the NTFS filesystem, things can maybe get a bit wobbly - this may be what tripped Gonzalo up?

Still, I think it's as good as a VBox VM, and it is easier to spin up an instance for a quick test or etc...

 

[Gonzalo Garramuño]

El 11/25/2023 a las 10:12 AM, Ian MacArthur escribió:
>
> I have copied (statically linked to fltk, but dynamically linked to
> the systemlibs) apps between this WSL2 setup and a real Ubuntu
> machine, and that has Just Worked, so this suggests to me that the
> libs and apps should be portable. The real Ubuntu was from an LTS
> branch that was essentially "the same" as the WSL2 machine though, so
> lib versioning probably would not be an issue - it might be with
> versions that were more dissimilar.

Indeed the system libs are no issue.  When I list ldd on the system
libs, they are all linking properly.

Regarding WSL2, the other nasty issue I found was that it is really
heavy for compiling.  When compiling with cmake and ninja-build and
spawning  the 16 cores of my machine, WSL2 would fork a Windows
Subsystem for Linux for each core, and it would bring the compilation to
a grinding halt once it reached hard to compile targets like FFmpeg.  
When compiling it through docker, WSL2 would not know I was compiling on
16 cores, and the compilation was as fast as a Linux system.

When compiling *with* WSL2, symlinks are turned into hard-links, at
least with the cmake (or is  it g++?) that is bundled with WSL2, so the
issue of symbolic link issues is also avoided, at the cost of bloat on
disk with the libraries taking two or three times the space on disk.

So, right now, I get half of the benefit right.  I can compile my
application on Linux for all distros and Windows under a single OS,
thanks to Docker (which *is* an amazing product, btw), but fully
compiling my application natively on WSL2 for Ubuntu is still a no-go IMO.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

El 11/25/2023 a las 10:12 AM, Ian MacArthur escribió:
>

> When you cross over between the WSL2 filesystem and the NTFS
> filesystem, things can maybe get a bit wobbly - this may be what
> tripped Gonzalo up?
>

Yes.  Symlinks do work on NTFS, they just don't work between a dual boot
of Windows and Linux.   That is, you either have symlinks on WSL2 or you
have symlinks on Linux, but not both.  The other thing that tripped me
was that from within WSL2 you could fire up Windows applications
directly.  So you have to be *really* careful with your PATH so that
you, for example, don't mix cmake, git or similar multi-platform tool
from Windows, WSL2 or MSys64 ("which" becomes your favorite tool).

I don't have another free hard-drive to test ext3/4, unfortunately.  I
chose NTFS as I wanted to share my code repository between Windows and
Linux on the same box.  Can you access ext3/4 from Windows without WSL2
or is that just within the WSL2 enclave?

If Windows would support ext3 or ext4 natively, they would also earn a
medal.

> Still, I think it's as good as a VBox VM, and it is easier to spin up
> an instance for a quick test or etc...

It *is* actually an improvement.  I used VBox VM and installation was a
pain, mounting shares with samba made compilation really slow and non
samba shares would not allow hard links and symlinks were supported thru
a hidden feature.

--
Gonzalo Garramuño
ggar...@gmail.com

[imm]

On Sat, 25 Nov 2023 at 17:23, Gonzalo wrote:
>
> I don't have another free hard-drive to test ext3/4, unfortunately. I
> chose NTFS as I wanted to share my code repository between Windows and
> Linux on the same box. Can you access ext3/4 from Windows without WSL2
> or is that just within the WSL2 enclave?
>
> If Windows would support ext3 or ext4 natively, they would also earn a
> medal.

Well... yes you can access the WSL enclave from the Windows side, but...

From the file explorer (at least for me) there's an entry for "Linux",
which then allows you to drill down into the WSL filesystem, and it
mostly seems to Just Work.
I can drill down Linux->Ubuntu->home->ian->etc...

From a DOS box (or equivalent) that is exposed as
\\wsl.localhost\Ubuntu\home\ian e.g. from a DOS shell

dir \\wsl.localhost\Ubuntu\home\ian

works as expected.

From an MSYS shell I need to escape that as:

ls -a "\\\\wsl.localhost\Ubuntu\home\ian"

to get the same effect; but it does work.

Similarly, the WSL runtime sees the Windows disks at /mnt/c and
/mnt/d and so on...


BUT: it seems to be Quite Slow in either direction, so whatever scheme
they use it does not look like Windows in natively reading the ext3 or
ext4 filesystem, or vice versa, rather it is going through some sort
of gateway and is not very fast.
This impacts my builds; if I use the WSL runtime to build things on
the NTFS filesystem it is very slow - but doing "the same" build
inside the WSL filesystem is much swifter.