Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update build instructions #7

Open
Shoozza opened this issue May 25, 2020 · 10 comments
Open

Update build instructions #7

Shoozza opened this issue May 25, 2020 · 10 comments
Assignees
Milestone

Comments

@Shoozza
Copy link
Member

Shoozza commented May 25, 2020

Current build instructions are missing a few steps when building from a clean system

@Shoozza Shoozza added this to the 1.8 milestone May 26, 2020
@Shoozza Shoozza self-assigned this May 26, 2020
@akiross
Copy link

akiross commented May 31, 2020

I tried building (for linux) from an ubuntu container, but failed with undefined references to protobufs (library was installed, though). I used PR #15 to get these deps:

build-essential g++ cmake git fpc libprotobuf-dev protobuf-compiler libssl-dev libsdl2-dev libopenal-dev libphysfs-dev libfreetype6

From the container, I could build the CMake version from @helloer repo, though.

@Wuzzy2
Copy link

Wuzzy2 commented Jul 14, 2020

For GNU/Linux, the build instructions in the README are kinda wrong and/or misleading. Here's a list of corrections and things I noticed:

  • You must write “make linux_x86_64” instead of make. If you only do make, it does not work
  • You don't actually need the prebuilt libraries if you have built them yourselves
  • Required version of the 3 "prebuilt" libraries should be written down
  • The binaries have a _64 appended to the end (at least on my system)
  • You can build libstb yourselves by typing cd client/libs/sdb followed by make in the console

@akiross
Copy link

akiross commented Sep 24, 2020

Thank you and sorry for the late answer.

  • specifying the linux target for make indeed works,
  • libstb compiled from client/libs/sdb seems to work ok,
  • I manually compiled GameNetworkingSocket, using the commit 8f60b0e6bf50b44d5cc6587b8ddcccc4d2a8e78c (as seen here) and copied that into shared/libs/GameNetworkingSocket
  • The build succeeds and all libs are found, but at runtime I get a
./soldat_x64: symbol lookup error: ./soldat_x64: undefined symbol: SteamAPI_ISteamNetworkingSockets_RunConnectionStatusChangedCallbacks

Which should have been solved by compiling GNS with that specific commit.

@akiross
Copy link

akiross commented Sep 24, 2020

Correction: I just used two different GNS versions. It works now (assets missing, but still).

@homerofgods
Copy link

homerofgods commented Dec 22, 2020

I tried building Soldat 1.8 but failed. I'm completely new to coding and such, but I have tried to learn how to use GitHub and various programs in hopes of trying out Soldat.
Updating the build instructions would be appreciated if it is possible to run the game. I want to see the current state of the game, and I even hope to learn enough to contribute with some easy tasks (text editing and translations perhaps)
In this, I am a slow learner, but I'm more dedicated than before and I never give up ;)

@BranDougherty
Copy link
Member

BranDougherty commented Dec 25, 2020

It feels to me like build instructions in this repo are in limbo until the CMake work gets merged. Until then easiest way to build (especially on Windows) is to clone @rzaba0 's v1.8.0 branch on his fork. Ideally, I think non-code contributions such as documentation and translation shouldn't require building from source. Just download nightly and build a PR.

@helloer
Copy link
Contributor

helloer commented Nov 12, 2021

CMake work has been merged, are we missing something in the build instructions?

@akiross
Copy link

akiross commented Nov 16, 2021

I'm on NixOS and everything went rather smooth with the current instructions, the only minor thing is that freetype was missing in my environment so I had to install it. So I guess it is fine for ubuntu, but I can't test there.

This is the shell.nix file I used to build and it worked:

with import <nixpkgs> { }; mkShell {
  nativeBuildInputs = [
    cmake
    fpc
    git
  ];
  buildInputs = [
    physfs
    openal
    SDL2
    protobuf
    openssl
    freetype
    xlibs.libX11
  ];
  APPEND_LIBRARY_PATH = with pkgs; lib.makeLibraryPath [
    SDL2
    physfs
    freetype
    xlibs.libX11
    openal
  ];

  shellHook = ''
    export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$APPEND_LIBRARY_PATH"
  '';
}

@BranDougherty
Copy link
Member

BranDougherty commented Nov 16, 2021

The instructions say to install libfreetype6 on Ubuntu and FreeType is listed in the dependencies. Here are some problems with the build instructions:

  • Downloading the prebuilt libraries is likely to fail on Linux if you are using a distribution other than Ubuntu (links to specific versions of libraries like libprotobuf.so.10). If you're using Linux, maybe you know this but maybe not, I think we should mention it.
  • I recently found out the Windows build was broken for a while due to problems with the FreeType 2.11 autohinter when built with MSVC (recently fixed by [freetype] Fix building Freetype 2.11 on MSVC. microsoft/vcpkg#20674). When we merge another PR the prebuilt libs should work again on Windows.
  • The Windows CMake debug build is broken because vcpkg adds a 'd' suffix to the debug libraries and we just link through the source code constants (with no suffix). A quick hack should be easy for that.
  • Why not flesh out the build instructions for Lazarus/Makefiles a bit.
  • I've had some success using this little utility cv2pdb to debug with visual studio. Also I had a problem where Lazarus chose the wrong gdb executable and I had to change it in settings. Maybe a separate BUILDING.md with also a section on debugging?

When at least these are fixed then I think we can close.

@SwamiUmami
Copy link
Contributor

* Why not flesh out the build instructions for Lazarus/Makefiles a bit.

I tried building Soldat with methods other than CMake, and encountered some problems when linking shared libraries. I think my fixes in #84 should move this issue a little forward 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants