Al* wrote:The only thing which seems a bit odd is that it says that there is a smokinguns 1.1. available.

I think this is the message of the day coming from the server you connected to. It just hasn't changed since the release.Just be sure that you have the 1.1 (I really doubt you got the old 1.0) installed.

"Chuck Norris had to shorten his beard in the presence of Richard Stallman because two beards that awesome, so close would segfault the universe (again)."

Thanks Barto and Téquila for helping us out - I was the one who suggested Al to post his problem here, since I didn't have an overview which x64 resources to point to.

Anyway, while the x86 binaries work on x64 bit Linux, a frequent problem seems to be the "missing (a 32bit?) libCURL" problem we have observed earlier and which is also the root of Al's post.

This makes me wonder, whether there is anything we can learn from this situation and which we could do to prevent it occurring at a next release. For instance, would it be possible to provide a built-in or packaged version of libcurl?

The HTTP downloading mechanism is more or less used as an update functionality of SG, by Baller Bude and other servers, thus it is becomes a critical part of SG.

Actually, the latest git revision of ioq3 has only the header files of libcurl (7.35). This shouldn't be that hard to add the code files too in the same folder and then edit the Makefile to compile it. To be honest, I'm no fan of this solution; I would prefer not to mix codebases and rely only on header files. Dependencies are here exactly for this: avoid code/library duplication.

For Windows or MacOS, I see that ioq3 has some pre-built binaries in code/libs/*, adding more of these files should also be a possibility not that hard to achieve (I haven't tried myself, I cannot judge the difficulty). Just don't fall on the solution to add ALL possible operating systems, otherwise you'll soon be compiling the game on Haiku :-p This will also add a ton of binaries in the source tree and we won't remember actually with which flags we compiled them.

The best would be to directly provide x86 and x86_64 binaries together in the release with a list of clear dependencies for the game. Some deb/rpm packages given upon release would be great.

"Chuck Norris had to shorten his beard in the presence of Richard Stallman because two beards that awesome, so close would segfault the universe (again)."

Actually, about libcurl, the difficulty was really the 64 bits flavour didn't build correctly. Now we can build x86_64 binaries I think we could forget to include libcurl in linux build.

Btw I agree on the fact static builds can help us to provide really independant builds. We can also just providing lighter libcurl build as libcurl would mostly be used for auto-download and for example we could just remove SSL support as it is huge in the code. Another nice lib could be interesting in the future is the one providing Freetype font support. Actually we don't have it for win builds but we can just have from the system on linux builds. So if we want to use Freetype we would have to build it for win, we can do it and we will do if necessary.

This is a matter of choice and I prefer now what the Barto still said:

The best would be to directly provide x86 and x86_64 binaries together in the release with a list of clear dependencies for the game. Some deb/rpm packages given upon release would be great.

Providing deb/rpm packages are still on my mind. As always, I just need some time to focus a little or maybe anyone else can do it.