Building on Mint 19.3 #94

Loki1950 · 2020-05-07T18:34:33Z

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 · 2020-05-07T19:00:14Z

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 · 2020-05-07T21:06:33Z

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 · 2020-05-08T01:10:54Z

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

BenjamenMeyer · 2020-05-08T04:06:03Z

@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 · 2020-05-08T10:06:19Z

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 · 2020-05-08T12:29:40Z

@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 · 2020-05-08T12:44:10Z

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

Loki1950 · 2020-05-08T13:01:01Z

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 · 2020-05-08T15:35:37Z

@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 · 2020-05-08T15:51:56Z

Will do later this afternoon

Loki1950 · 2020-05-08T19:30:14Z

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 · 2020-05-08T19:41:09Z

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 · 2020-05-08T21:12:26Z

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 · 2020-05-08T21:29:04Z

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 · 2020-05-08T21:36:09Z

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

ermo · 2020-05-08T22:05:11Z

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:

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.
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
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 · 2020-05-08T22:10:36Z

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

BenjamenMeyer · 2020-05-09T02:23:25Z

@ermo the APT line in #94 (comment) 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 · 2020-05-09T12:35:58Z

[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 · 2020-05-09T14:47:28Z

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 · 2020-05-09T16:10:52Z

Still getting a sharedlib

Loki1950 · 2020-05-10T02:16:34Z

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 · 2020-05-10T02:41:09Z

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

ermo · 2020-05-10T09:10:00Z

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 · 2020-05-10T11:34:56Z

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 · 2020-05-10T11:38:27Z

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 · 2020-05-11T00:30:06Z

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 · 2020-05-11T06:20:18Z

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 · 2020-05-11T11:02:09Z

Where is the breakage define it.

nabaco · 2020-05-11T18:18:36Z

I see two options here:

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

BenjamenMeyer · 2020-05-11T18:28:45Z

@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 · 2020-05-11T18:46:28Z

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 · 2020-05-11T19:37:33Z

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 · 2020-05-11T19:43:17Z

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 · 2020-05-11T19:53:18Z

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 · 2020-05-11T23:43:52Z

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 · 2020-05-12T00:08:58Z

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 · 2020-05-12T15:48:18Z

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 · 2020-05-12T16:13:13Z

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

BenjamenMeyer · 2020-05-12T16:16:42Z

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.

Loki1950 · 2020-05-12T17:24:41Z

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

ermo · 2020-05-12T17:53:28Z

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 · 2020-05-12T17:56:18Z

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

ermo · 2020-05-12T19:24:29Z

@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 · 2020-05-12T20:11:15Z

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

ermo · 2020-05-12T21:34:58Z

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 · 2020-05-12T21:56:41Z

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

Older versions of Ubuntu and its derivates have an issue where the `file` utility will interpret Position Independent Executables as shared libraries: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1747711 As a workaround, allow setting the option COMPILE_WITH_FPIE (defaults to OFF) and add a suitable message for maintainers in both the CMake code, during configuration runs and in ccmake. Update the build instructions in the README to reflect this change. Closes vegastrike#94

ermo · 2020-05-12T22:23:21Z

@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 · 2020-05-13T14:57:50Z

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

BenjamenMeyer added this to Needs triage in All the bugs via automation May 7, 2020

BenjamenMeyer added the bug label May 7, 2020

BenjamenMeyer added this to the 0.7.x milestone May 7, 2020

nabaco moved this from Needs triage to Normal priority in All the bugs May 7, 2020

ermo mentioned this issue May 12, 2020

Set -fno-PIE by default as a Ubuntu/Mint workaround #112

Merged

BenjamenMeyer closed this as completed in #112 May 13, 2020

All the bugs automation moved this from Normal priority to Closed May 13, 2020

Building on Mint 19.3 #94

Building on Mint 19.3 #94

Comments

Loki1950 commented May 7, 2020 • edited Loading

Loki1950 commented May 7, 2020

Loki1950 commented May 7, 2020 • edited by nabaco Loading

Loki1950 commented May 8, 2020

BenjamenMeyer commented May 8, 2020

ermo commented May 8, 2020 • edited Loading

Loki1950 commented May 8, 2020

BenjamenMeyer commented May 8, 2020

Loki1950 commented May 8, 2020

ermo commented May 8, 2020

Loki1950 commented May 8, 2020

Loki1950 commented May 8, 2020 • edited Loading

ermo commented May 8, 2020 • edited Loading

Loki1950 commented May 8, 2020

ermo commented May 8, 2020 • edited Loading

Loki1950 commented May 8, 2020

ermo commented May 8, 2020 • edited Loading

Loki1950 commented May 8, 2020

BenjamenMeyer commented May 9, 2020

Loki1950 commented May 9, 2020 • edited Loading

ermo commented May 9, 2020 • edited Loading

Loki1950 commented May 9, 2020

Loki1950 commented May 10, 2020

Loki1950 commented May 10, 2020 • edited Loading

ermo commented May 10, 2020

Loki1950 commented May 10, 2020

Loki1950 commented May 10, 2020 • edited Loading

Loki1950 commented May 11, 2020

ermo commented May 11, 2020

Loki1950 commented May 11, 2020

nabaco commented May 11, 2020

BenjamenMeyer commented May 11, 2020

nabaco commented May 11, 2020

ermo commented May 11, 2020

BenjamenMeyer commented May 11, 2020

ermo commented May 11, 2020 • edited Loading

stephengtuggy commented May 11, 2020

Loki1950 commented May 12, 2020

Loki1950 commented May 12, 2020

BenjamenMeyer commented May 12, 2020

BenjamenMeyer commented May 12, 2020 • edited Loading

Loki1950 commented May 12, 2020

ermo commented May 12, 2020 • edited Loading

BenjamenMeyer commented May 12, 2020

ermo commented May 12, 2020

nabaco commented May 12, 2020

ermo commented May 12, 2020 • edited Loading

BenjamenMeyer commented May 12, 2020

ermo commented May 12, 2020 • edited Loading

Loki1950 commented May 13, 2020

Loki1950 commented May 7, 2020 •

edited

Loading

Loki1950 commented May 7, 2020 •

edited by nabaco

Loading

ermo commented May 8, 2020 •

edited

Loading

Loki1950 commented May 8, 2020 •

edited

Loading

ermo commented May 8, 2020 •

edited

Loading

ermo commented May 8, 2020 •

edited

Loading

ermo commented May 8, 2020 •

edited

Loading

Loki1950 commented May 9, 2020 •

edited

Loading

ermo commented May 9, 2020 •

edited

Loading

Loki1950 commented May 10, 2020 •

edited

Loading

Loki1950 commented May 10, 2020 •

edited

Loading

ermo commented May 11, 2020 •

edited

Loading

BenjamenMeyer commented May 12, 2020 •

edited

Loading

ermo commented May 12, 2020 •

edited

Loading

ermo commented May 12, 2020 •

edited

Loading

ermo commented May 12, 2020 •

edited

Loading