search

vegastrike / Vega-Strike-Engine-Source

Vega Strike Engine
Other
260 stars 43 forks source link

Building on Mint 19.3 #94

Closed Loki1950 closed 4 years ago

Loki1950 commented 4 years ago

Having great difficulty building do not get an executable get vegastrike: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=7037dafcdf95535245ab216b3e22191299d30af8, not stripped

Loki1950 commented 4 years ago

gcc version 4:7.4.01ubuntu2.3 cmake version 3.10.2-1ubuntu2.18.04.1 uname -a 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux boost version 1.65.1

Loki1950 commented 4 years ago

Here it my error log error.log

$ ls -lF build/
total 16
drwxr-xr-x 2 denis denis 4096 May  7 16:54 CMakeFiles/
-rw-r--r-- 1 denis denis 1178 May  7 16:54 cmake_install.cmake
-rw-r--r-- 1 denis denis 4483 May  7 16:54 Makefile
Loki1950 commented 4 years ago

Still getting a sharedlib but it does work from the cmd line in a terminal will try @ermo 's elfedit hack tomorrow

BenjamenMeyer commented 4 years ago

@Loki1950 interesting - I get a binary, and KDE prompts about what to do with it when I double-click - asking to either Execute or Cancel.

I think the normal means is to provide FreeDesktop Entry File (see https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) which would get installed to /usr/share/applications (at least on Linux).

ermo commented 4 years ago

To be clear, my "elfedit hack" was a suggestion to try elfedit --output-type=exec ./vegastrike to see if that would allow the binary to be run from the DE.

My hypothesis is that, for some reason, @Loki1950 's Linux Mint 19.3 build apparatus isn't setting the ELF type correctly during the linking phase.

@Loki1950 does it make any difference if you build with -DSYSTEM_BOOST rather than the default vendored (and apparently soon-to-be-dropped) Boost?

Loki1950 commented 4 years ago

@ermo haven't tried yet I tend to use what works and it works for me now @BenjamenMeyer I don't install VS most of the time I run it in userland much easier to update asset errors

BenjamenMeyer commented 4 years ago

@Loki1950 I haven't installed it yet myself, just run using symlinks in the asset directories (e.g git submodules).

Loki1950 commented 4 years ago

With svn I used to have a directory under my Project one that I called Playground or Sandbox which was an export of the data (striped the .svn folders out)

ermo commented 4 years ago

@ermo haven't tried yet I tend to use what works and it works for me now

Could you please try compiling newest master with -DSYSTEM_BOOST=ON so that we can rule out the Boost version used as the culprit?

Loki1950 commented 4 years ago

Will do later this afternoon

Loki1950 commented 4 years ago

Still get a sharedlib vegastrike: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=e0d93d08c1b7be6a4ed56d9e564ddfcfe206cc23, not stripped

ermo commented 4 years ago

Still get a sharedlib vegastrike: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=e0d93d08c1b7be6a4ed56d9e564ddfcfe206cc23, not stripped

(emphasis mine)

That interpreter ~path~filename looks wrong. On my system, it is /usr/lib64/ld-linux-x86-64.so.2

Would you be willing to try to reinstall your glibc and binutils packages, reboot and rebuild newest VS master and paste the file vegastrike output again?

I would also do a sudo touch /forcefsck to force the system to do a full fsck of your root filesystem during the next reboot. You might possibly want to do this before attempting to re-install anything actually.

FWIW, I have the fsck.mode=force kernel command-line option set such that my system runs fsck on each and every boot before mounting my root fs.

Loki1950 commented 4 years ago

Sorry I will not that would in effect break my system I have no /lib64 under /usr what is under /usr/lib are folders for installed packages and symbolic links to lib's .so reminder each distro interprets the standard in it's own way till you can prove to me that your interpretation is valid period I gave up the bloody noses when I drop fedora I have a stable system BTW my laptop also shows the same structure also a Mint 19.3 install so it does indeed seem to be Distro policy

ermo commented 4 years ago

Sorry I will not that would in effect break my system I have no /lib64 under /usr what is under /usr/lib are folders for installed packages and symbolic links to lib's .so reminder each distro interprets the standard in it's own way till you can prove to me that your interpretation is valid period I gave up the bloody noses when I drop fedora I have a stable system BTW my laptop also shows the same structure also a Mint 19.3 install so it does indeed seem to be Distro policy

You misunderstand -- I'm suggesting that /lib64/l looks weird and that I would expect it to be at the very least /lib64/ld-linux*.so*. My comments weren't about distro policy at all; I don't care where the files live and what the distro policy is for a given distro. =)

Running a file system check and then asking your package manager to re-install packages shouldn't break your system unless the package manager is seriously broken (which I doubt is the case for Mint/Ubuntu given that you're on a mature LTS).

But in any case, if you refuse to perform troubleshooting steps which can help determine whether what you are seeing is down to a local issue or not, then you should probably close this bug as invalid, since there'll effectively be no way to determine what the root cause is and since none of us are able to reproduce your issue.

Your call.

Loki1950 commented 4 years ago

Can you give me the proper apt cmd line and the fsck

ermo commented 4 years ago

Can you give me the proper apt cmd line and the fsck

I already posted the fsck part (but you could be forgiven for missing it):

I would also do a sudo touch /forcefsck to force the system to do a full fsck of your root filesystem during the next reboot. You might possibly want to do this before attempting to re-install anything actually.

FWIW, I have the fsck.mode=force kernel command-line option set such that my system runs fsck on each and every boot before mounting my root fs.

See also https://mintguide.org/system/283-how-to-check-and-fix-the-disk-for-errors-and-bad-sectors-in-linux-mint.html

It looks like the Ubuntu glibc package is split up into libc6 and libc-bin

Binutils is binutils.

So to see what would happen on a re-install, you would do a:

sudo apt-get install --reinstall --dry-run binutils libc6 libc-bin

But in any case, if I were in your shoes, I would do things in the following order:

  1. Run a quick SMART disk test to check if the disk has reported any errors or bad sectors. If you spot strange looking numbers, I would encourage you to run a full SMART disk test overnight.
  2. Once the SMART testing part is complete, run sudo touch /forcefsck and reboot to have Mint run fsck on your disks during the next boot
  3. After the disk check has run, re-install glibc and binutils as shown above (you can remove the --dry-run parameter once you're satisfied that things look sane).
Loki1950 commented 4 years ago

Thx will do the Smart test over night the in the process of cooking my supper

BenjamenMeyer commented 4 years ago

@ermo the APT line in https://github.com/vegastrike/Vega-Strike-Engine-Source/issues/94#issuecomment-626040911 looks right; generates the following:


$ sudo apt-get install --reinstall --dry-run binutils libc6 libc-bin
[sudo] password for bmeyer: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 4 reinstalled, 0 to remove and 1 not upgraded.
Inst libc-bin [2.30-0ubuntu2.1] (2.30-0ubuntu2.1 Ubuntu:19.10/eoan-updates [amd64])
Inst libc6 [2.30-0ubuntu2.1] (2.30-0ubuntu2.1 Ubuntu:19.10/eoan-updates [amd64])
Inst libc6:i386 [2.30-0ubuntu2.1] (2.30-0ubuntu2.1 Ubuntu:19.10/eoan-updates [i386])
Conf libc6 (2.30-0ubuntu2.1 Ubuntu:19.10/eoan-updates [amd64])
Conf libc6:i386 (2.30-0ubuntu2.1 Ubuntu:19.10/eoan-updates [i386])
Conf libc-bin (2.30-0ubuntu2.1 Ubuntu:19.10/eoan-updates [amd64])
Inst binutils [2.33-2ubuntu1.2] (2.33-2ubuntu1.2 Ubuntu:19.10/eoan-updates, Ubuntu:19.10/eoan-security [amd64])
Conf binutils (2.33-2ubuntu1.2 Ubuntu:19.10/eoan-updates, Ubuntu:19.10/eoan-security [amd64])
$
Loki1950 commented 4 years ago 

[sudo] password for denis: 
Sorry, try again.
[sudo] password for denis:         
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 4 reinstalled, 0 to remove and 7 not upgraded.
Inst libc-bin [2.27-3ubuntu1] (2.27-3ubuntu1 Ubuntu:18.04/bionic [amd64])
Inst libc6 [2.27-3ubuntu1] (2.27-3ubuntu1 Ubuntu:18.04/bionic [amd64])
Inst libc6:i386 [2.27-3ubuntu1] (2.27-3ubuntu1 Ubuntu:18.04/bionic [i386])
Conf libc6 (2.27-3ubuntu1 Ubuntu:18.04/bionic [amd64])
Conf libc6:i386 (2.27-3ubuntu1 Ubuntu:18.04/bionic [i386])
Conf libc-bin (2.27-3ubuntu1 Ubuntu:18.04/bionic [amd64])
Inst binutils [2.30-21ubuntu1~18.04.3] (2.30-21ubuntu1~18.04.3 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Conf binutils (2.30-21ubuntu1~18.04.3 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])```
ermo commented 4 years ago

Complete build instructions with relevant output for comparison:

ermo@rocinante:~/src/Vega-Strike-Engine-Source ⑂master*
$ git pull --all
Fetching upstream
Fetching origin
Already up to date.
ermo@rocinante:~/src/Vega-Strike-Engine-Source ⑂master*
$ rm -rf build
ermo@rocinante:~/src/Vega-Strike-Engine-Source ⑂master*
$ mkdir -pv build
ermo@rocinante:~/src/Vega-Strike-Engine-Source ⑂master*
$ cd build
ermo@rocinante:~/src/Vega-Strike-Engine-Source/build ⑂master*
$ cmake -DCPUINTEL_native=ON -DCPU_SMP=4 -DCMAKE_BUILD_TYPE=Debug ../engine
++ Python release(s) searched for : 2.7
++ Python library : /usr/lib/libpython2.7.so (2.7.18)
++ Python include dir : /usr/include/python2.7
++ Looking for System Boost::python (py2)
++ Found System Boost version : 106600
++ Found System Boost::python (py2) : /usr/lib/libboost_python.so
++ OpenGL found : /usr/lib/libOpenGL.so;/usr/lib/libGLX.so;/usr/lib/libGLU.so
++ GLUT found : /usr/lib/libglut.so;/usr/lib/libXi.so
++ Found OpenAL
++ SDL Found
-- Found Vorbis: /usr/lib/libvorbis.so;/usr/lib/libvorbisfile.so;/usr/lib/libogg.so
-- FFMPEG disabled
-- Ogre disabled
CMake Warning (dev) at /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (GTK2).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/share/cmake-3.17/Modules/FindPkgConfig.cmake:45 (find_package_handle_standard_args)
  FindGTK2.cmake:32 (include)
  setup/CMakeLists.txt:15 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found GTK2: /usr/lib/libgtk-x11-2.0.so;/usr/lib/libgdk-x11-2.0.so;/usr/lib/libgdk_pixbuf-2.0.so;/usr/lib/libgmodule-2.0.so;/usr/lib/libgthread-2.0.so;/usr/lib/libgobject-2.0.so;/usr/lib/libpango-1.0.so;/usr/lib/libpangocairo-1.0.so;/usr/lib/libatk-1.0.so
-- Compiling mesh_tool without OgreMesh support: Ogre not found
Default build type is Release, no cpu opts enabled. 
Building with BUILD_OPT: -O2
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ermo/src/Vega-Strike-Engine-Source/build
ermo@rocinante:~/src/Vega-Strike-Engine-Source/build ⑂master*
$ time make -j4
(... most of the build output left out for brevity ...)
[100%] Building CXX object CMakeFiles/vegastrike.dir/src/python/briefing_wrapper.cpp.o
[100%] Linking CXX executable vegastrike
[100%] Built target vegastrike

real    6m0.776s
user    22m3.574s
sys     1m54.688s
ermo@rocinante:~/src/Vega-Strike-Engine-Source/build ⑂master*
$ cd ..
ermo@rocinante:~/src/Vega-Strike-Engine-Source ⑂master*
$ ls -F build/
build/          cmake_install.cmake  libnetgeneric.a   Makefile  vegaserver*
CMakeCache.txt  config.h             libnetlowlevel.a  objconv/  vegastrike*
CMakeFiles/     libengine_com.a      libOPcollide.a    setup/
ermo@rocinante:~/src/Vega-Strike-Engine-Source ⑂master*
$ file build/vegastrike 
build/vegastrike: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7b22b37ca8fe067087209ecd0da1c6ef5f7c32ed, for GNU/Linux 3.14.32, with debug_info, not stripped
Loki1950 commented 4 years ago

Still getting a sharedlib

Loki1950 commented 4 years ago

Still feel that we are missing something will do some google fu tomorrow see if has turn up somewhere else as my kernel modules build properly many the nVidia kernel interface though is is a dynamic build when I update the kernel besides the Mint/Ubuntu maintainers do it so there must be some documentation.

Loki1950 commented 4 years ago

Possible answer https://stackoverflow.com/questions/46551213/gcc-7-2-compiles-shared-library-instead-of-executable

ermo commented 4 years ago

Quote from https://askubuntu.com/questions/690631/executables-vs-shared-objects:

Another difference is that executables have a defined entry point address offset, i.e., 0x08048000 for i386, 0x00400000 for x86 and 0x00010000 for arm.

A shared object file can be a library, but also an executable. When being an executable, there is no such offset. A shared object executable, so to say, is a positional independent executable (PIE) using address space layout randomization (ASLR). Thus, when looking at its /proc/pid/maps file, you will notice that the location of the loaded segments vary in each execution in contrast to standard executables.

It would not surprise me if the problem relates to file or, more likely, the library file uses to query the type of the file. The library hypothesis would also explain why your file manager sees the same classification.

Could you please paste the output of ldd file and ldd dolphin here?

The hypothesis that the object code really is a "shared object executable" (PIE) is supported by the fact that you can execute it from the command line.

Could you double check whether your compiler adds a compilation flag containing pie somewhere? It should be visible in your build log.

Bonus points for investigating and reporting it as a bug to Ubuntu as necessary (since Mint will pull in any fixes related to this).

Loki1950 commented 4 years ago

Again could you be more specific lld file and ldd dolphin on whatdenis@denis-750-229:~$ ldd file ldd: ./file: No such file or directory

Loki1950 commented 4 years ago

As noted on the stackoverflow answer Arch now uses pie as the default Ubuntu seems to following that lead and would declare no bug intended behaviour.Arch sees it as closing a security hole.

Loki1950 commented 4 years ago

And yes I do see pie in the CMakeOutput.log several times actually but the first is

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
Loki1950 commented 4 years ago

This reminds of my first compiles on the IBM 360 relocatable objects where the default at that time early 70's as well.

Loki1950 commented 4 years ago

Just tried to double-click vegastrike using Dolphin and it starts up no problem though the icon for it is question mark.

ermo commented 4 years ago

Again could you be more specific lld file and ldd dolphin on whatdenis@denis-750-229:~$ ldd file ldd: ./file: No such file or directory

ermo@rocinante:~
$ which file
/usr/bin/file
ermo@rocinante:~
$ ldd $(which file)
        linux-vdso.so.1 (0x00007ffe0d9d4000)
        libmagic.so.1 => /usr/lib/libmagic.so.1 (0x00007f598e898000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f598e6a8000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f598e678000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f598e658000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007f598e8f8000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f598e630000)

Don't do it for dolphin -- the list of dynamic libs pulled in by dolphin is endless.

If you could figure out which package each of the files above belong to, that would be useful. I don't know how you would do that on Mint, but I'm sure Google does.

ermo commented 4 years ago

Just tried to double-click vegastrike using Dolphin and it starts up no problem though the icon for it is question mark.

Another data-point in favour of the "Mint's version of file (or one of the libraries file relies on) has trouble understanding PIE shared object executables"-hypothesis.

Loki1950 commented 4 years ago 
denis@denis-750-229:~$ ldd $(which file)
    linux-vdso.so.1 (0x00007ffe6bd75000)
    libmagic.so.1 => /usr/lib/x86_64-linux-gnu/libmagic.so.1 (0x00007fcabf7fd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcabf40c000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcabf1ef000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcabfc25000)
stephengtuggy commented 4 years ago

I don't think it's @Loki1950 's system. I think the same behavior happens on all Ubuntu-based systems. (Or possibly all Debian-based, going up a step further.)

stephengtuggy commented 4 years ago

The difficulty with the ELF shared binary being what is produced? I get that too. From what I can tell, anyway.

Loki1950 commented 4 years ago

From the reddit thread linked in the stackoverflow answer Arch made pie default behaviour as far back as gcc 7.2 as a security precaution the the Ubuntu family followed but it looks like they did not update file to understand the change

Loki1950 commented 4 years ago

@stephengtuggy could you post the the packages that provide the libs that ldd $(which file) produces your more familiar with apt-get than I

Loki1950 commented 4 years ago

In the interim can we add CFLAGS=-no-pie the the cmake arguments that seems to be what is being recommended else where.

stephengtuggy commented 4 years ago

In the interim can we add CFLAGS=-no-pie the the cmake arguments that seems to be what is being recommended else where.

@Loki1950 I think we should do the opposite. From what you're saying, the PIE functionality is a security improvement. Let's leave that in place, if we can.

And it sounds like this problem is on Ubuntu, not us. Would it be acceptable to leave this ticket as is? Now that we've figured out how to build and run Vega Strike from the command line, at least? Or do we want to keep working on it, trying to find a better solution?

Loki1950 commented 4 years ago

From the googling I have done that is what most of Ubuntu's package maintainers have been doing it is something that started with version 7.2 of gcc so it's been around for a while the -no-pie hack does seen to have become accepted practice as for the security issue it fairly obscure IMO most users will expect that double-clicking is the way to start the app

ermo commented 4 years ago

From the googling I have done that is what most of Ubuntu's package maintainers have been doing it is something that started with version 7.2 of gcc so it's been around for a while the -no-pie hack does seen to have become accepted practice as for the security issue it fairly obscure IMO most users will expect that double-clicking is the way to start the app

Adding a compilation flag to make the binary work properly because the distribution defaults result in breakage seems ... odious at best.

If we do decide to create a work-around, it might make sense to guard it behind a /etc/lsb-release check and thus make it clear that it's not our fault that some distributions can't be bothered to fix known bugs.

Loki1950 commented 4 years ago

Where is the breakage define it.

nabaco commented 4 years ago

I see two options here:

  1. Change CMakeLists.txt to test specifically for Mint 19, and in that case remove the --pie option
  2. Add in the README/FAQ a note regarding this issue, and close it.
BenjamenMeyer commented 4 years ago

@nabaco The --pie option is probably affecting all Ubuntu-based, may be even all Debian-based, distros. So for the moment, I'd suggest number 2 from your list, and perhaps #97 might add some help in resolution too.

nabaco commented 4 years ago

I don't know, I don't see this issue on Ubuntu on my side. Though I haven't checked on 20.04 yet.

ermo commented 4 years ago

The problem here is that you have a SNAFU where the compilation succeeds and looks innocent, but the binary appears broken.

Speaking from experience (just look how long it took for us to investigate this!) this kind of error is the worst kind of insidious.

So, on reflection, the only reasonable outcome is to take a clear stance by either refusing to compile if there's a risk of the binary issue, or alternatively, make it go away by providing an automatic workaround. Which, again, begs the question if VegaStrike should be held accountable for quirky/slightly-broken distributions that apparently don't care enough to actually fix their mess.

As a maintainer, my stance (after experiencing a particularly annoying recent build error with the julia package in Solus) is that I'd rather have a hard error and having the workaround clearly documented in the build instructions, because I can then mark it as a distribution bug with a patch in my package script and my commit log and drop said patch when the distribution bug goes away and note why in the associated commit.

As @Loki1950 said, the packagers for the affected distributions already know that this is a common problem. I say we let them deal with it then.

BenjamenMeyer commented 4 years ago

Based on what @stephengtuggy and @Loki1950 have noted, I'm probably seeing this on Kubuntu 19.10 (essentially Ubuntu 19.10 + KDE); only difference is that KDE prompts about running it. It runs fine from the command-line, but double-clicking in Dolphin gives a prompt that I wouldn't normally get.

I agree with @ermo that we need to push back on Debian/Ubuntu to fix this as it's a lot wider spread issue than just us.

ermo commented 4 years ago

Slightly tongue-in-cheek proposal for build system error-gating:

If we encounter a possibly-broken distribution (egrep -iq 'debian|mint|ubuntu' /etc/lsb-release), require a flag to be set (e.g. -DMY_PIE_IS_A_LIE=ON) for the compilation to succeed.

The error text can be a carbon copy of the text warning we will henceforth provide in the README so that packagers won't have any excuse to ignore it.

stephengtuggy commented 4 years ago

I am all for pushing back on Debian/Ubuntu to fix this.

@Loki1950 do you have a link(s) to the thread(s) you were reading on this subject?

Loki1950 commented 4 years ago

Just followed those from the stackoverflow I posted earlier the reference to Arch's reasoning is a link to a reddit post while it points to the Arch-dev-public mailing list and the one that @ermo posted from askubuntu

Loki1950 commented 4 years ago

What would I do locally so I get a old style executable so I can start verifying all of the units my tool chain for this starts with @pyramid3d UnitConvertor which calls mesher (mesh_ tool) and vegastrike as well as nvtt (NVIDIA texture tools) the nvtt no longer looks to be available for Linux so I have gotten the Flatpack version of GIMP 2.10 with includes the dds plug-in.