Vega-strike-engine-source: Building on Mint 19.3

[Loki1950]

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]

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]

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]

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

[BenjamenMeyer]

@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]

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]

@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]

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

[Loki1950]

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]

@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]

Will do later this afternoon

[Loki1950]

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]

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]

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]

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]

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

[ermo]

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]

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

[BenjamenMeyer]

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

```bash
$ 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]

sudo apt-get install --reinstall --dry-run binutils libc6 libc-bin [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]

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]

Still getting a sharedlib

[Loki1950]

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]

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

[ermo]

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]

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]

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]

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]

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

[Loki1950]

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

[ermo]

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]

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]

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]

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]

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

[Loki1950]

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]

@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]

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

[stephengtuggy]

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]

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]

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]

Where is the breakage define it.

[nabaco]

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]

@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]

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]

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]

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]

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]

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]

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]

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.

[BenjamenMeyer]

Here's a bug filed with Ubuntu: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1747711

[BenjamenMeyer]

Seems a common work around is to add the -no-pie option to GCC/G++ flags, see https://stackoverflow.com/questions/45329372/ubuntu-recognizes-executable-as-shared-library-and-wont-run-it-by-clicking.

For the time being, while a PIE is generally more secure since it makes things fully relocatable, based on the bug I found (see https://github.com/vegastrike/Vega-Strike-Engine-Source/issues/94#issuecomment-627443369) there doesn't seem to be a good way for file and other tools to detect the difference between a shared object library and a shared object executable, and no one seems to be really trying to solve that.

Further, I tried doing #97 and it doesn't seem to resolve it either.

So until Ubuntu or whomever is upstream can fix this we probably should enable -no-pie and document that fact so that folks can use vegastrike without getting weird prompts that will make it look like we can't build an executable. Many are not going to want to resort to the command-line.

[Loki1950]

So which file do I add -no-pie and where ie: line #

[ermo]

Seems a common work around is to add the -no-pie option to GCC/G++ flags, see https://stackoverflow.com/questions/45329372/ubuntu-recognizes-executable-as-shared-library-and-wont-run-it-by-clicking.

For the time being, while a PIE is generally more secure since it makes things fully relocatable, based on the bug I found (see #94 (comment)) there doesn't seem to be a good way for file and other tools to detect the difference between a shared object library and a shared object executable, and no one seems to be really trying to solve that.

Further, I tried doing #97 and it doesn't seem to resolve it either.

So until Ubuntu or whomever is upstream can fix this we probably should enable -no-pie and document that fact so that folks can use vegastrike without getting weird prompts that will make it look like we can't build an executable. Many are not going to want to resort to the command-line.

cmake 3.5.x (used by Ubuntu 16.04 LTS) supports the option CMAKE_POSITION_INDEPENDENT_CODE.

This is the text I have written for the option and which I am now testing locally:

# On some Debian and Ubuntu versions and derivatives, a bug exists whereby
# enabling PIE compilation (Position Independent Executables) results
# in the OS incorrectly recognising the compiled vegastrike binary as a
# shared library instead of a position independent shared executable object.
#
# To avoid this scenario, turn off this flag by default and let packagers
# on other distributions turn this on if their OS is able to correctly deal
# with Position Independent Executables.
#
# For more info, see:
#
# - https://bugs.launchpad.net/ubuntu/+source/file/+bug/1747711
#
# - https://github.com/vegastrike/Vega-Strike-Engine-Source/issues/94
#
OPTION(POSITION_INDEPENDENT_EXECUTABLES "Enable Position Independent Executables (NOT recommended for Debian/Ubuntu/Mint)"
  OFF )
IF(POSITION_INDEPENDENT_EXECUTABLES)
  message("!! Enabling Position Independent Executables (NOT recommended for Debian/Ubuntu/Mint) !!")
  SET(CMAKE_POSITION_INDEPENDENT_CODE ON)
ENDIF(POSITION_INDEPENDENT_EXECUTABLES)

[BenjamenMeyer]

@ermo looks good; can you please also include a link to the Ubuntu Bug in the CMakeLists.txt change?

[ermo]

@ermo looks good; can you please also include a link to the Ubuntu Bug in the CMakeLists.txt change?

Done (see above).

Still testing whether the code I have written actually does anything -- I remain unconvinced at this stage, but we'll see...

[nabaco]

@ermo if you have any success, feel free to open a PR

[ermo]

Still testing whether the code I have written actually does anything -- I remain unconvinced at this stage, but we'll see...

I think I've got it working now:

• I've verified that the default (PIE off) adds a -fno-PIE flag when compiling executables
• I've verified that enabling PIE adds a -fPIE flag when compiling executables
• If the user compiling vegastrike adds either -fPIE or -fno-PIE to the CMAKE_CXX_FLAGS_${BUILDTYPE} manually, disabling the PIE option adds -fno-PIE after the manual flags, thus overriding them as far as I can tell.

In the PR, I'm also going to change the suggested build invocation from make to cmake --build . because it allows for adding -v which will show the compiler command-line (very useful when capturing debug logs when building).

[BenjamenMeyer]

@ermo thanks!

Question: which do we want to be default? What makes it painful? or easy?

To push back on distros it seems which should make it painful (per earlier discussion); but at the same time I'm inclined to put the users first.

Thoughts?

[ermo]

@ermo thanks!

Question: which do we want to be default? What makes it painful? or easy?

To push back on distros it seems which should make it painful (per earlier discussion); but at the same time I'm inclined to put the users first.

Thoughts?

I'm defaulting COMPILE_WITH_FPIE to OFF to avoid confusing packagers and hapless users compiling on their own.

At the same time, I have added a suitably snarky comment in README.md referencing the launchpad bug in question.

[Loki1950]

Just did an update of file security regression not our issue looking at the change log but it does mean the maintainers are active