On Sat, Sep 1, 2018 at 9:22 AM bmullan <[email protected]> wrote:
> Nick > > So I read your response and this is fixed in v1.0 master or branch but as > users we don't know when that might become available. > We're nearing completion on 1.0.0. It has a couple of outstanding issues that need to be completed/fixed, and then some documentation to wrap up. I hope it's a matter of weeks, but most of us that contribute to the project have day jobs that don't involve actively contributing to the project, so we can only work so fast. Unfortunately for me it's a hobby, not a career :-). You can check the 1.0.0 version out from the Github mirror repo (staging/1.0.0 branch): https://github.com/apache/guacamole-server if you go this route you'll also need to build the guacamole client code of the same version due to the number of changes made: https://github.com/apache/guacamole-client > > Is there anyway to get this "fix" included into the current 0.9.14 release > ? > I'm sure you could patch the 0.9.14 source with this fix - the code for the fix is relatively simple: https://github.com/apache/guacamole-server/pull/150 It should be pretty easy to patch the 0.9.14 code. The Guacamole project will not release an official fix for it, though (aside from the 1.0.0 version) - we do not go do any official back-ports of patches to already-released code. > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: > ‘__builtin___sprintf_chk’ output between 8 and 2055 bytes into a > destination > of size 2048 > > There are a lot of 3rd party "build" scripts for Guacamole which I assume > fail now due to this and may be causing new users of Guacamole alot of > frustration trying to install it. > Probably so - there's a reason we don't claim or support those third party scripts. The build process is well-documented within the project, and we fix issues like this within the repository. We definitely do not want the process to be frustrating for people; however, sometimes those third party build scripts only compound the frustration. They're fine when they work, but when they don't you have the added steps of having to debug the build script on top of what might actually be broken in code. The only thing we officially support in that area is the Dockerfile build that is part of the repositories - Docker is the way the project has decided to take to automate Guacamole builds. Beginning with 1.0.0 we have/will take(n) a new approach to versions in Guacamole that should allow us to release patches and minor version increments much more quickly, which will enable us to respond better to scenarios like this. 1.0.0 is nearing completion, and, after that we will probably have another version out relatively quickly as we're already accumulating quite a list of fixed issues in the master version of the repo. Looking beyond 1.0.0 we want to be able to quickly/easily release patch versions (e.g. 1.0.1) and minor versions (1.1.0) more quickly and maintain compatibility across major versions of Guacamole (1.x.x). Hopefully this will mean more than one release per year, which, as a long-time user of open source projects, I fully understand can be frustrating - I've experienced it myself more than once. > > Searching for a solution myself I saw a long thread about this error on a > redhat user forum where they were blaming the failure to build guacamole on > the gcc compiler version and several other wrong conclusions. > > Same thing with ubuntu users trying to build guacamole for the 1st time (I > use ubuntu 18.04 but know its not the gcc ver and was aware of your fix for > v1.0 Guacamole whenever it gets released. > Yeah, and this particular change is a hotly-debated issue among many software developers. The change in GCC has caused many, many issues with various software builds, and a lot of people are not happy about it, but the GNU Compiler folks have stuck to their guns and there are fixes available. Sometimes they just take a while to come out. > > Many of those people may not know to how or want to /"check out either the > master or staging/1.0.0 branch and build from there" / > I certainly understand this, and we want to get 1.0.0 out as quickly as we can. For the time being, your options are: - Check out the Git repos for 1.0.0 or master and build that way. - Grab the code from the pull request above and patch the 0.9.14 version of the code. - Stick with 0.9.14 and install with a compiler that is known to work. This may mean using Ubuntu 16.04 or CentOS7 or some other combination of known-good platforms. There are several that still work and compile correctly. I use CentOS7, and, while it means I have to compile newer versions of FreeRDP manually because the packages are so old, it's stable and works well long-term. Ubuntu 16.04 is a LTS version, is stable where it is, is known to compile Guacamole correctly, and is still supported and active. - Use the Docker images (available in Docker hub). - Nick
