I also tried compiling AssimpNet and MGCB without luck. I even tried cmaking assimp also without luck. I also tried extracting the libdl.so and related files from the package that was working on Ubuntu 16.04 but “luckily” Linux is not scanning for .so files in random places to avoid malicious injection. Maybe these attempts can also help spawn ideas.
1 Like
I ran into this as well. I created a symlink for libdl.so.2 to libdl.so and this fixed it. After updating to the newest glibc with pacman, it restored the previous libdl.so so I no longer have the symlink, but it still works for me to build fbx files. Not sure if this would work for you but I would try creating that symlink on your popOS installation. It shouldn’t break anything
As for running the editor, it will fail on linux because of a conflict with an update to gtk. This is fixed in the development branch of monogame and if you compile, you should be able to run it. However, I’ve just gotten used to running mgcb from the terminal and editing my content project file directly.
2 Likes
I’ve created symlinks too and it worked like a charm! Thanks a lot!
I think that treat a symptom not the cause, but great for a temporary solution.
2 Likes
Awesome, I’m glad that worked for you! Just a heads up, if you update your wine version past I think 7.4, you won’t be able to compile effects on linux.
Creating the symbolic link makes the compilation of FBX files work on my Pop!_OS 22.04 installation.
For anyone wanting to create the symbolic link, this is the command I used:
ln -s /usr/lib/x86_64-linux-gnu/libdl.so.2 /usr/lib/x86_64-linux-gnu/libdl.so
Your paths might differ so figure out where your libdl.so.2 file is located and use that path.
Thanks @servvs! That was an easy fix 
1 Like
Since the original issue with Assimp could be solved with the creation of a symlink if I understand correctly. Is the thing with the wine prefix architecture still a thing? I think it is and it is something not related but you found it while searching for the solution, right? Can you explain in detail the steps I need to take to see the issue and then I can try if extracting the dotnet 3.1 stuff to the suggested folder solves that? So you said dotnet.exe could not be found by wine. Which commands do I have to use or what exact steps do I need to reproduce it?
I could add the change myself probably but I thought maybe it would be a good idea to do it through GitHub. I am not experienced with the workflow there but I think you could open an issue and / or do a pull request (after you cloned the repository and commited the change to some branch)? Maybe you know already and we can figure this out if you like?
@Kwyrky I recorded a video of how to get to the point where 3D model content compilation fails. In the end of the video you can see it fails finding libdl.so which is a Linux library which means dotnet command is running from Linux and not Wine/Windows. After following the video you should be at a place where anything you do with dotnet command is not running from within Wine/Windows but Linux.
I had to split the video in two parts as I’m not allowed to upload videos longer than 15 minutes.
Part 1 My InstallMonoGameLinuxScript issue (Part 1/2) - YouTube
Part 2 My InstallMonoGameLinuxScript issue (Part 2/2) - YouTube
I agree that the symbolic link is not a solution for everything that your script is aiming at solving. After the symbolic link you are still not able to compile effects (.FX) files. Adding the symbolic link to your could be a good idea though I have no idea how well it works on other Linux distributions.
So just to be on the same page here, the script is basically only the collection of manual commands you can run one by one when going through the official documentation of MonoGame. What I noticed when I did the manual installation, there where some things missing to make the mgcb-editor work and to be able to compile fx files and spritefont files. I just added what was necessary to make those things work. On Ubuntu and the tested Linux Mint distros this seems to work as intended.
Now of I understand correctly you are trying to do content compilation using the dotnet command on the content builder task dll which I never tried. Only by running / building the project or with the mgcb-editor I tried building the content.
When I find some time I could test if this works using your method of calling the content builder task dll.
I don’t know exactly how it works under the hood but maybe looking at the source of the mgcb-editor would be helpful. So maybe then if there is happening something different or special when building the content doing the same when executing the command with the content builder task dll will make it work?
I watched the videos. Does it make a difference of you logout and login again? This makes sure the environment variables or something are set. Not sure right now if this is necessary for what you are doing just something I remember and just to rule this out to cause issues.
Also not sure but running the script as sudo is not necessary and maybe is the reason for other issues. I could not remember ao I quickly checked my youtube recording of running the script and I just execute the script without sudo as regular user. Then when root rights are necessary the script will ask for it.
Maybe logout and login (session restart) and then switching to the root user works (after running the installation script with sudo… 
)
sudo passwd root (enable root)
su - (become root user)
sudo passwd -dl root (disable root)
@Kwyrky it didn’t help logging out and then in again, I even tried rebooting.
I did another attempt with a clean Ubuntu but this time without sudo as you suggested and it was much easier to do all the stuff, but I still have the same error when running dotnet build to compile Cube.fbx.
Logout / login or reboot should have the same effect, that the environment variables are then active for all terminals. I don’t remember but for the terminal where the install script has been run it is added temporary. This can be checked by printing them out either by printing all of them or explicitly the ones which are needed. If I remember correctly they are only used by mgcb-editor to find the wine prefix and architecture.
The demo apps are just the template project (just if you create one by hand with the dotnet cli) and the other one has two content files in it, a FX file and a SpriteFont. So if the cornflower blue and monogameorange are started at the end of the installation with the script then the compilation of those work as expected I would say. This was basically what I tried to provide with the script.
For the FBX I don’t know…
Does the FBX get built on Ubuntu and Linux Mint?
If you use / install the symlink, does this fix it?
I have not tested FBX building on Linux Mint. I can however say that it worked on Ubuntu 16.04 without symbolic link and again on 22.04 when using the symbolic link. In theory, your script should also make FBX compilation work, I have just not been successful doing that yet. I’m sure I will figure it out at some point as it doesn’t make sense to make that it is not working with the FBX. I will post the solution when I figure it out.
1 Like
I have figured out why shader compilation works better with Wine than 3D model compilation. The effect compiler mgfxc actually has a redirect to Wine built in into the code
The content compiler mgcb does not have this check and therefore does not “redirect” the execution to Wine. This explains why the script does not solve the 3D model compilation issue. The symbolic link could help with that, but maybe not on all Linux distributions.
If the symbolic link solution proves to be incompatible with various Linux distributions then another “solution” might be to have the script modify the MonoGame.Content.Builder.Task.targets and MonoGame.Content.Builder.Task.props files to point to the mgcb.exe in Wine.