Linux buildfixes

[flibitijibibo]

The following series of patches are quick buildfixes for Linux. For the most part they're harmless, but there are two issues of note:

• While this allows the Amnesia/AmnesiaDemo/Launcher targets to be built, the dev tools will still not build - this is also true for Windows as well though. Until we have the tests/ directory for SimpleCamera, there's not much we can do about that. EDIT: Directory was added, all targets link now!
• The dependencies.zip does not have valid symlinks, so the linker will still bail when building the final executable. This is easy enough to fix locally by rebuilding them, but it may be a moot point when builds start using system libraries anyhow.

[ericonr]

@flibitijibibo I was thinking of trying to use https://gitlab.com/Mr_Goldberg/goldberg_emulator in place of Steamworks. Do you know if that's possible?

[flibitijibibo]

It's probably functional, but I believe the Steamworks code has been stripped out anyway (which is probably the right thing to do) so it would only fix the link process. I think it was just used for achievements anyway so it's probably not a huge deal...

[coolreader18]

I get a weird error when linking MshConverter.bin.x86_64 with the vorbis shared lib:

/usr/bin/ld:/home/coolreader18/AmnesiaTheDarkDescent/HPL2/dependencies/lib/linux/lib64/libvorbisfile.so: file format not recognized; treating as linker script
/usr/bin/ld:/home/coolreader18/AmnesiaTheDarkDescent/HPL2/dependencies/lib/linux/lib64/libvorbisfile.so:1: syntax error

HPL2/dependencies/lib/linux/lib64/libvorbisfile.so just has this inside:

link libvorbisfile.so.3.3.5

and HPL2/dependencies/lib/linux/lib64/libvorbisfile.so.3.3.5 is a valid so file. I'm not to familiar with linker scripts, is that a legitimate error or something with my setup? I've got GNU ld 2.35 on arch linux.

[fennecdjay]

I have a similar error as @coolreader18, also on arch.

[k0pernicus]

Got the same error as @coolreader18.
I first tried to link myself the libvorbisfile.so.3.3.5 to libvorbisfile.so but got linker issues (skipping incompatible <LOCAL_PATH>libvorbisfile.so when searching for -lvorbisfile) at the end...

Same for vorbis, ogg, openal, ...

[flibitijibibo]

Per the OP:

The dependencies.zip does not have valid symlinks, so the linker will still bail when building the final executable. This is easy enough to fix locally by rebuilding them, but it may be a moot point when builds start using system libraries anyhow.

The .so files will be labeled as ASCII text when you check them with file, those are the links that need to be rebuilt.

[k0pernicus]

Thanks.

After rebuilding the links I have this: /usr/bin/ld: <LOCAL_PATH>/libvorbisfile.so: error adding symbols: file in wrong format.

I suppose this is a build architecture issue, right? :thinking:

[fennecdjay]

Any hints at how to rebuild dependencies?

[k0pernicus]

@fennecdjay I suppose you have to rebuild only the links.

So, for <LOCAL_PATH>/libvorbisfile.so you can do this:

cat <LOCAL_PATH>/libvorbisfile.so # note the linked .so (LINKED_SO) here, should be libvorbisfile.so.3.3.5
rm <LOCAL_PATH>/libvorbisfile.so
ln -s <LOCAL_PATH>/<LINKED_SO> <LOCAL_PATH>/libvorbisfile.so

and do this for all of the .so files...

[robalni]

Here is a quick way to recreate the links. Run it from the directory the so files are in.

for f in `file * | grep ASCII | cut -d: -f1`; do ln -fs `cut -d' ' -f2 $f` $f; done

And when there is a message about "file in wrong format", try replacing the lib directory with lib64.

[coolreader18]

@robalni that worked after I ran it in lib/linux/lib64 and lib/linux/lib, thanks! Now I've got the same error that k0pernicus does

[fennecdjay]

I still have problems with the libs, also I have

/media/DOC3/Jeux/AmnesiaTheDarkDescent/HPL2/tools/modelview/ModelView.cpp:22:10: erreur fatale: ../../tests/Common/SimpleCamera.h : Aucun fichier ou dossier de ce type
   22 | #include "../../tests/Common/SimpleCamera.h"

which I have no clue how to fix.

[flibitijibibo]

Per the OP (again):

While this allows the Amnesia/AmnesiaDemo/Launcher targets to be built, the dev tools will still not build - this is also true for Windows as well though. Until we have the tests/ directory for SimpleCamera, there's not much we can do about that.

To fix pretty much all of the linker issues you will all most likely want to focus on removing the use of local dependencies and linking to the system libraries instead.

[robalni]

@aeiouaeiouaeiouaeiouaeiouaeiou I get similar error as the first one you got when I try cmake in the core directory. Try instead the directory amnesia/src.

[flibitijibibo]

If patch review isn't being done there may be a better place for discussion - there isn't a place on the forum for the Amnesia source yet but it may be worth bringing up: https://www.frictionalgames.com/forum/

Other issues unrelated to this patchset should be filed separately.

[Mudbill]

I've had a fair few compile errors complain about:

relocation R_X86_64_32S against .rodata can not be used when making a PIE object; recompile with -fPIE

The fix I've used to progress past it is to add the -no-pie compile flag, not the -fPIE flag, inside the cmake files.

[juliosueiras]

yea, also stuck at needing the SimpleCamera.h as well, this is what I currently have in nix for this

with import <nixpkgs> {};

stdenv.mkDerivation {
  name = "AmnesiaTheDarkDescent";

  src = fetchFromGitHub {
    repo = "AmnesiaTheDarkDescent";
    owner = "FrictionalGames";
    rev = "master";
    sha256 = "yaym9rOb7/FjW2TESJdC4v7yknn+20zaC7T4kHqyKSY=";
  };

  buildInputs = [ cmake libGL.dev libGLU.dev xorg.libX11.dev ];

  patches = [
    (fetchpatch {
      url = "https://github.com/FrictionalGames/AmnesiaTheDarkDescent/pull/2.patch";
      sha256 = "jElow6Str+sPJdH3deCzaAa4uraZYTz4wGyJyDOi/GA=";
    })
  ];

  postPatch = ''
    pushd .
    cd HPL2
    ${unzip}/bin/unzip dependencies.zip -d dependencies
    popd

    sed -i 's;/usr/bin/perl;${perl}/bin/perl;g' ./HPL2/core/buildcounter.pl
  '';

  cmakeDir = "../amnesia/src";
}

[juliosueiras]

actually never mind, SimpleCamera.h look like is at https://github.com/FrictionalGames/HPL1Engine/tree/master/tests/Common

[juliosueiras]

seem to be the same name but different internal implementation , so not really usable

[coolreader18]

Yup, I tried that as well, it seems like an older version, especially since that's hpl1 and this is hpl2

[juliosueiras]

oh well, I guess is time to wait until tests folder get uploaded

[frictional-edvin]

Hey I just added SimpleCamera.h/cpp!

Give it a go and let me know if there's anything else missing!

[brynet]

@frictional-edvin wrote:

let me know if there's anything else missing!

The sources for the prebuilt dependencies (w/ any modifications) would be helpful, for example the version of Newton (2.0) used by HPL2 appears to be unavailable online, it's unclear if Amnesia will compile with later versions of the API (3 & 4) found here.

It is also not currently possible to build Amnesia or HPL2 entirely from source, without any prebuilt dependencies until the (singular?) proprietary component fbxsdk-2012.2-static can be replaced (or stubbed out?). *

* These are not criticisms, just musings from someone who looked into porting to an unsupported platform.

[flibitijibibo]

Force-pushed to match the latest revision. It looks like a CMake file was missing but I'm assuming there's a ton of custom stuff in there, so I added a quick file to cover the two new files, and everything links successfully now.

This should be good to merge again!

[sthilaid]

I've had a fair few compile errors complain about:

relocation R_X86_64_32S against .rodata can not be used when making a PIE object; recompile with -fPIE

The fix I've used to progress past it is to add the -no-pie compile flag, not the -fPIE flag, inside the cmake files.

What's the best way to do that? I'm not very familiar with cmake... Thanks!

[Mudbill]

@sthilaid I have a full video on it here, but basically you edit the CMakeLists.txt file in several locations, particularly in amnesia/src and HPL2/core. At the bottom of the file, add set(CMAKE_CXX_FLAGS "-fpermissive -no-pie") (fpermissive is mentioned earlier in this thread).

[ericwomer]

Per the OP:

The dependencies.zip does not have valid symlinks, so the linker will still bail when building the final executable. This is easy enough to fix locally by rebuilding them, but it may be a moot point when builds start using system libraries anyhow.

The .so files will be labeled as ASCII text when you check them with file, those are the links that need to be rebuilt.

The problem here isn't the broken shared links but even when building on 64bit it still tries to link to the 32bit libraries in the HPL2/dependencies/lib/linux/lib folder and not the HPL2/dependencies/lib/linux/lib64 folder like it should.

[Mudbill]

The problem here isn't the broken shared links but even when building on 64bit it still tries to link to the 32bit libraries in the HPL2/dependencies/lib/linux/lib folder and not the HPL2/dependencies/lib/linux/lib64 folder like it should.

I haven't had that happen to me. My system has picked the 64-bit libraries in lib64 each time.

[sthilaid]

@sthilaid I have a full video on it here, but basically you edit the CMakeLists.txt file in several locations, particularly in amnesia/src and HPL2/core. At the bottom of the file, add set(CMAKE_CXX_FLAGS "-fpermissive -no-pie") (fpermissive is mentioned earlier in this thread).

Thank you very much. This worked perfectly. I already had fixed the errors mentionned that are avoided by the permissive flag, but didn't know how to tell g++ to use -no-pie :). I only modified the root CMakeLists.txt file and the HPL2/core/CMakeLists.txt files and it was sufficient. (I'm working on the a machine for pigs repo though).

Cheers!

[flibitijibibo]

Looks like a force-push blew this apart - should I rebase and resubmit?

[ericwomer]

Yeah, it could still help, don't know why they closed this.

[brynet]

It looks like commit history was lost as of 4 hours ago, @frictional-edvin, what happened here? Was this an accident?

[Mudbill]

It was intentional. I believe it was to remove the FBX SDK due to licensing restrictions, so now that has to be added separately.

[ericwomer]

There have been tons of projects that have to remove licensed material that didn't nuke their entire history.

[Mudbill]

In that case I'm not sure why the history was removed. You can ask Edvin. He's most likely to reply in the Discord server.