afaik the glib version required is whatever you have on the build system or higher, if arch ships with 2.28 everybody that runs your build will needs 2.28+ . The build bots i think run on the oldest supported LTS ubuntu release for this exact reason which is on 2.24.
AKH! If I can get my hands on 2.24 for Arch, is there any way to tell cmake to use that, instead?
In theory, I could grab an older binary from Debian and temporarily link to it, run make, then reinstate the current libc. Thoughts?
I don’t think you can swap out glibc versions that easily, but i have to admit not my platform.
No, no… I certainly wasn’t implying that I just replace the ACTUAL link. That’ll cripple the system! LOL!!!
No, I meant to tell cmake to look at another libc.so.6, then change it back. That’s something that I’ll have to look into, but if anyone there knows, let me know.
Quick google turned up this, looks messy and you’re definitely in uncharted territory there. Elsewhere on the forum are a couple of centos 7 dockers were posted (glib 2.17 i think) perhaps that’s an easier option?
Yeah, I’ve already been reading A TON of scenarios, already. There’s even a chrooted build environment you could build, but at that point, come on.
The only option I like is to build it on a Debian-based system. It won’t go as far back as GLIB_2.24, but it’ll be less bleeding edge, than Arch.
Just wanted to inform all who have helped me figure a few technical things out, that I’ve successfully built the latest static version of Blender sculpt-mode-features and have posted it on the NEW GraphicAll channel on blender.community for testing. I compiled it with GLIBC_2.27+ support, since going the GLIBC_2.24 wasn’t going to happen (it’s just too old for our studio - lol!).
Good to Know. When you have time, it would be nice to have a tutorial about the steps you followed. Something cleaner to read and understand than this whole thread.
The thing is, most build errors are highly environment specific, you’ll have a hard time coming up with a guide that has every single problem imaginable in it. Building things is hard, we try to catch the most common errors, but it’s impossible to get a fool proof guide, especially if more advanced building techniques like fully static builds are in play.
I will, indeed, come up with a tutorial, as soon as I have time. It’s important. It’ll be imperfect, but it’ll help the individual navigate the unique gotchas on their own systems.
Right. That’s why when I write it, it’ll have to instruct how to navigate those waters. There are some things concrete and others very fluid. I’ll have to carefully instruct on those fluid parts.
Of course, it won’t be a free-for-all, either. I’m only going to describe how to make static builds for better sharing. Libs built in. Unless there’s a good reason now to. You guys know best.
I am grateful to Blender developers for making Blender easy to compile/build in Linux. “install_deps.sh” script resolving dependencies for major distros is really a good thing, and I’m grateful for that to developers.
How could it be made easier to build portable builds for Linux without it meaning a lot of maintenance work for developers?
Perhaps supporting only one of the most popular distros? For example some kind of script that installs everything necessary for Ubuntu 14.04.
Another option could be that you officially share a VM image with a Linux system specially prepared to build portable builds? That VM system could be updated periodically from an script for the user. And when necessary, you renew and share a new VM image.
I do not know.
I’ve seen several dockers for this purpose, there’s even a long thread on this forum for building on Centos 7 which has an ancient glibc so that would make builds with maximum compatibility.
The thing is you’ve reached advanced building territory, we can’t hold your hand forever, tutorials are out at a certain point, exploring, experimenting and being comfortable failing on your own are required habits at that stage. Yeah it’s scary, but have a go at it, it just may be fun! 
I’m in the middle of writing the tutorial on compiling a static lib Blender build for Linux. I’m a bit unsure about how to checkout more than one branch. My experience with git worktree commands is limited and the ones in the docs I’m not sure are complete, or not.
For example, if I have origin checked out by default and I want to add sculpt-mode-features in parallel, how would I do it and update both branches properly?
Personally i just work by checking out branches as i need them? There is really rarely a need to have two branches checked out at the same time. If recompilation time is an issue just use something like ccache deal with it
But in all honesty, If you’re making a tutorial on building things, i wouldn’t muddy the water too much by including optional other advanced subjects. Great idea for a future tutorial perhaps?
That’s what I’ve been doing all this time. That will be the main thrust of my tutorial, which I’m in the middle of battle-hardening by building and posting three different branches for testing on the new incarnation of GraphicAll.
git worktree method is something I’m thinking of adding as an appendix item, as it were. I’ve since made a lot of headway on the matter. Though, I agree, that getting complicated from the get-go will turn would-be first-time-builders away awful fast. Thanks for the input.
I recently got some feedback from a user from GA, who stated that executing my builds from CLI worked fine, but double-clicking looked for an associated programme. I jumped on to an Ubuntu/Linux Mint system and confirmed that it is indeed the case. It works fine with Arch. The file is compiled and packaged as executable. What’s missing here?
Here’s a link, in case you want to try it out on an Ubuntu(Debian?)-based system:
Thanks, folks.
CMAKE_EXE_LINKER_FLAGS = -no-pie
e.g. via cmake gui would link that as executable again instead of as shared library.
As easy as that, eh?
Done! On all three branch builds that I’ve been providing for GA. Thanks, @scorpion81.
Now that I have your ear for a spell, can I have your opinion on something? Is it a good idea to limit my builds of your branch to once a week? Is Friday a good day to do that? I know that it’s a bit mercurial, but generally speaking, what’s good and fair?
Attempting to build latest sculpt-mode-features, which has new remesher options using QEX lib. However, when compiling the lib, I get:
[ 33%] Built target QExStatic
make[5]: *** No rule to make target '/home/haig/blender-git/build_linux/deps/Release/openmesh/lib/OpenMesh/libOpenMeshCore.a', needed by 'libQEx.so'. Stop.
make[4]: *** [CMakeFiles/Makefile2:110: CMakeFiles/QEx.dir/all] Error 2
make[3]: *** [Makefile:130: all] Error 2
make[2]: *** [CMakeFiles/external_qex.dir/build.make:116: build/qex/src/external_qex-stamp/external_qex-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:2120: CMakeFiles/external_qex.dir/all] Error 2
make: *** [Makefile:130: all] Error 2Any ideas on what CMakeCache option to add/change?