On 07/07, Alexander Neundorf wrote: > On Tuesday, July 07, 2015 14:36:25 Steve Borho wrote: > > Hello, I am the technical lead for x265 (HEVC encoder) and we have used > > cmake successfully since the beginning of the project. There are a few > > rough edges that we've had to work around (uninstall rules, yasm support > > in MSVC, etc) but in general it has worked pretty well. > > > > x265 can support a number of bit-depth options, but these are compile > > time decisions. You must chose at build time whether the encoder will > > use 8bit, 10bit, or 12bit color samples internally. Recently we've > > resolved the naming conflicts and thus allow these multiple builds of > > libx265 to be linked together into a single binary. > > > > The way the multilib build process currently works is it creates 8bit/ > > 10bit/ and 12bit/ folders, then runs cmake in each seperately (with > > different options) so there are three distinct build folders. It builds > > 10bit and 12bit first, outputting only static libraries, then finally it > > builds the 8bit folder and adds the 10bit and 12bit static libraries to > > the 8bit shared library link target. > > > > This works well on Windows and Mac but on x86_64 Linux I get this error: > > > > /bin/ld: common/CMakeFiles/common.dir/x86/pixel-a.asm.o: relocation > > R_X86_64_PC32 against symbol `x265_pw_1' can not be used when making a > > shared object; recompile with -fPIC > > > > (in a nutshell, the 10bit and 12bit static libs are no longer position > > independent) > > > > I figure there are multiple potential solutions for this and would > > welcome pointers for any of them > > > > 1 - is there a way for the project to re-include itself? If so we could > > have the 8bit build simply build the 10 and 12bit object libraries and > > link with those directly and bypass the creation of static libraries. > > This would perhaps be optimal since you would end up with a single > > Makefile driving the whole build. > > > > 2 - is there some invocation that will force cmake to build the static > > libraries such that they are still safe for linking into a shared > > library? > > > > I've already tried these unsuccessfully: > > set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) > > set_target_properties(x265-static PROPERTIES POSITION_INDEPENDENT_CODE > > TRUE) set_target_properties(x265-static PROPERTIES LINK_FLAGS "-fPIC") > > > > 3 - is there another intermediate format that cmake can output that > > preserves -fPIC, or some way to access the object libraries of the > > other external builds? > > > > 4 - is there any post-processing that can be done on the static libs to > > make them safe for shared libs again (guessing this is not likely) > > did you already have a look at the "object libraries" (created using > add_library(... OBJECT...) ? Those basically just build the object files, and > can later be used to link into other targets.
We use object libraries internally, but I don't know how the 8bit build can access the object libraries from the 10bit or 12bit builds. -- Steve Borho -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake