guess there’s no proper fix to make it work in both scenario :\
guess there’s no proper fix to make it work in both scenario :\
Proper fix is not having broken c++ headers on your OS. I’d have to talk to the maintainer of that piece of code if he’s wiling to accept the patch but i haven’t bumped into him in a few days.
wondering whether using : https://developers.redhat.com/products/developertoolset/hello-world/#fndtn-rhel
could be an option.
source scl_source enable devtoolset-7
once installed and enabled I get:
$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-7/root/usr --mandir=/opt/rh/devtoolset-7/root/usr/share/man --infodir=/opt/rh/devtoolset-7/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --with-default-libstdcxx-abi=gcc4-compatible --with-isl=/builddir/build/BUILD/gcc-7.3.1-20180303/obj-x86_64-redhat-linux/isl-install --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)
maybe this is just too new though.
source scl_source enable devtoolset-6
gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-6/root/usr --mandir=/opt/rh/devtoolset-6/root/usr/share/man --infodir=/opt/rh/devtoolset-6/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=gcc4-compatible --with-isl=/builddir/build/BUILD/gcc-6.3.1-20170216/obj-x86_64-redhat-linux/isl-install --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
This might be better
Both should probably work? dunno, you’d have to try.
Just about to.
I’ll try with 6.3.1 first as is the closer to a list of requirements I have .
Hi @LazyDodo, seems to be working fine now with the new compiler (no error during the compilation, but still need to extract the result from the docker and test it.)
the new docker for 2.8 is here : https://bitbucket.org/snippets/efestolab/GeREgb/docker-blender-build-centos-7
feel free to test if you fancy, and thanks a lot for the support
ps. seems to be working fine.
If someone want to test here is the result build
running the deps build for every build, yikes that can’t be easy on the resources
I’ve different plans for the dependencies…
also when you run
cpack -G tgz it’ll package up blender nicely, include the stuff you need, leave out the stuff you don’t
aha, I’ll add that
I’m trying to redirect the dependencies file (all , built etc…) to a specific location, so I can create a base dependencies docker for blender.
I’ve been having a look at the cmake and thought having these set before running make deps would have been enough :
ENV DEPS_INSTALL_DIR /opt/blender/lib ENV DEPS_BUILD_DIR /opt/blender/lib_build
but in the output I can still see
– Installing: /tmp/blender-git/lib/linux_x86_64/ffmpeg/lib/libvorbisfile.a
– Installing: /tmp/blender-git/lib/linux_x86_64/ffmpeg/lib/libvorbisenc.a
– Installing: /tmp/blender-git/lib/linux_x86_64/ffmpeg/lib/libvpx.a
– Installing: /tmp/blender-git/lib/linux_x86_64/ffmpeg/lib/libx264.a
– Installing: /tmp/blender-git/lib/linux_x86_64/ffmpeg/lib/libxvidcore.a
guess these should be passed directly to the make deps command rather than having them set as environment ?
(sorry really not skilled at all with cmake)
If there’s any extended documentation about the build deps and code you can point me to is appreciated.
Fixed that now, previously it was not possible to override these variables:
Note that you will also need to set
-DLIBDIR=/tmp/blender-git/lib/linux_x86_64 when building Blender to make it find these libraries.
Thanks @brecht !
I’ll give this a shot asap !
seems to be working like a charm
-- Installing: /opt/blender/lib/tiff/include/tiffvers.h -- Installing: /opt/blender/lib/tiff/include/tiffconf.h -- Installing: /opt/blender/lib/tiff/lib -- Installing: /opt/blender/lib/tiff/lib/libtiff.a -- Installing: /opt/blender/lib/tiff/lib/libtiffxx.a -- Installing: /opt/blender/lib/ffmpeg/lib/libvorbis.a -- Installing: /opt/blender/lib/ffmpeg/lib/libvorbisfile.a -- Installing: /opt/blender/lib/ffmpeg/lib/libvorbisenc.a -- Installing: /opt/blender/lib/ffmpeg/lib/libvpx.a -- Installing: /opt/blender/lib/ffmpeg/lib/libx264.a -- Installing: /opt/blender/lib/ffmpeg/lib/libxvidcore.a
@brecht, sorry for my ignorance here.
is it possible this is for cmake ?
I’m using make full , and either passing as argument or setting it as env does not seems to be working.
Is there any other option ?
the makefile is generally used for convenience it’ll do the right thing for most people, if you need more customizations you’re probably better off by running cmake your self directly.
make full really does is call
mkdir buildfolder cd buildfolder cmake -C"/pathtosourcedir/build_files/cmake/config/blender_full.cmake" make
Cheers, this seems more convenient indeed …
more questions to follow for sure
Lot to work on , but the dockers are taking shape and I’ve been moving them to a repo:
thanks all for the help again
do you know if cpack -G RPM works ?
I’ll give it a go asap, but just to know if there’s anything about it to know beforehand.
I have no idea , as I mentioned before, i’m the windows maintainer so very rarely deal with linux, an old system riddled with build issues sounded like fun so i took a quick stab at centOS
I have used the msi/zip/7z packagers and those work wonderfully, although the MSI builder needs quite some configuration/settings to produce a proper installer. could be that RPM needs some similar handholding before it’ll make a workable package (or it could work straight out of the box, you’ll just have to try and see)
and Good to know ! This gives me hope for the rpm as well , it might be matter of having a bunch of libraries installed , but I’ve the feeling won’t be enough
Anyhow, not a priority for now, as still lot to cleanup in the docker before getting there, but again , really useful.
I just applied the patch to work around the const iterators, so it should no longer be needed to apply that manually.