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

Compile statically? - For Docker containers #263

Open
qdm12 opened this issue Nov 15, 2018 · 10 comments
Open

Compile statically? - For Docker containers #263

qdm12 opened this issue Nov 15, 2018 · 10 comments

Comments

@qdm12
Copy link

qdm12 commented Nov 15, 2018

Hi there !

I made a Debian Slim based Docker container with your server. I had to go the Debian way as your program needs g++-multilib to run. I would ideally like to run cod4x on Alpine Linux or even Scratch, but to do so, I would need to compile cod4x fully statically, without this g++-multilib dependency. Any indication on how to do that would be greatly appreciated ! If this is not feasible, a more narrowed list of runtime dependencies would also be appreciated !

Thank you!

@qdm12
Copy link
Author

qdm12 commented Nov 19, 2018

Hi there,

I fixed it by adding the -static flag to the Makefile. There is now a 6.57MB Scratch based container running your server ! Except I had to trim out everything 32 bit else (steam, xbase_00.iwd) etc. as they would not work on scratch.

I might do an Alpine version to allow at least xbase_00.iwd to be copied.

@qdm12 qdm12 closed this as completed Nov 19, 2018
@D4edalus
Copy link
Contributor

sorry that nobody took the time to respond. could you fork the server and commit the changes? might be useful in future.

@qdm12
Copy link
Author

qdm12 commented Nov 19, 2018

Do you mean fork your repository? You can simply do that with sed -i 's/LINUX_LFLAGS=/LINUX_LFLAGS=-static /' makefile

For now the version I have is missing steam features:

Error: Sys_LoadLibrary error: steam_api.so: cannot open shared object file: No such file or directory
Error: steam_api.so not found or it was not possible to load. Error is: no error occurred while loading shared library. Steam is not going to work.

It does not seem to see the files although they are there. It seems like it's a 32bit/64bit issue from using ldd. I will try it out on Alpine Linux instead of Scratch. Why are these steam*.so files needed?

Thanks for your answer!

@D4edalus
Copy link
Contributor

D4edalus commented Nov 19, 2018

you said something about trimming everything 32bit .. so i thought you did more than that.
"Except I had to trim out everything 32 bit else"
you aren't compiling the server in 64bit , are you?

if the steam_api.so isn't loading i would assume that another dependency required by it is missing. you should be able to run the server without them. they are required to authenticate players.

@qdm12
Copy link
Author

qdm12 commented Nov 19, 2018

Oh, no sorry! As in the server runs on a 64 bit container but I it's still compiled in 32 bit I think. And do you know where I can find the source to compile steam_api.so statically perhaps? That would allow me to save on the Docker image space. Also what are the certificates in the xbase_00.iwd used for? Thanks!

@D4edalus
Copy link
Contributor

ah alright, i would have been very surprised if it was compilable for 64 bit :D

steam_api.so is closed source. what's the point of fighting for a few megabytes as the gamefiles require a few gigabytes anyways? i think the certificates are required to validate the identity of the update server. i would have to check to be certain.

@qdm12
Copy link
Author

qdm12 commented Nov 19, 2018

What would be the point of compiling to 64 bit? The performance is enough as it is now, right?

If you run multiple servers in parallel or if your resources are limited, there would be an impact Docker-wise. For example my previous Debian image would use twice the amount of ram in comparison with the current Scratch one. It's also for convenience for other users to download (10MB vs 350MB).

I'll finish polishing the Alpine image hopefully making the steam libraries working.

@D4edalus
Copy link
Contributor

i was referring to the static compilation of steam_api.so
And do you know where I can find the source to compile steam_api.so statically perhaps? That would allow me to save on the Docker image space.

i get that scratch vs debian is much smaller, but i don't get why compiling steam_api.so should make a difference.

@qdm12
Copy link
Author

qdm12 commented Nov 19, 2018

Oh ok sorry for misunderstanding!
It's just that steam_api.so doesn't work without its dependencies (such as debian and g++ multilib = 350MB) which I don't know. A solution would be to to compile it statically but if it's closed source, it's a dead end!

I did a remake (not pushed yet) with Alpine Linux instead of scratch and everything works except Steam_api.so. Not a deal-breaker, but it would be great to have a fully working cod4x 😉

Again, thanks for your help and this wonderful project allowing to continue playing this (10 years old?) game!

@qdm12
Copy link
Author

qdm12 commented Apr 26, 2020

Hello again, I'm still redigging into the static compilation 😉

Compiling the cod4x server statically using this works, but it won't work with the Steam files and therefore the server won't show on the masterlist.

After digging around making the .so steam files and cod4x_dedrun work without other dependencies , I have some questions:

  1. where do you get the steam files from? Although they are closed source, maybe there could be a statically compiled version?
  2. Do we actually need the ~300MB g++-multilib to make cod4x_dedrun work with steam? Would you perhaps have a list of more precise packages to install to fill the dependencies needed? I tried ldd cod4x_dedrun, ldd steam_api.so and ldd steamclient.so but I still cannot figure all the packages needed to make them work sadly.
  3. Using the statically compiled cod4x18_dedrun seems to not work with the steam files even if g++-multilib is installed, any idea why?

Anyway, thank you so much for still maintaining this project and your help!

@qdm12 qdm12 reopened this Apr 26, 2020
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

2 participants