Blender 2.71 does not linking properly against this library version without the addition of this flag. I've attached the modified ebuild, feel free to modify it further (e.g. you can also add -DBUILD_STATIC_LIBS=ON if you want both shared and static, or you can add that flag conditionally with the use flag static-libs that used to exist in the older ebuilds). Reproducible: Always Steps to Reproduce: 1. emerge blender Actual Results: blender tries to link with multiple libraries with the symbols defined, and I believe with multilib it tries to link to both the 32 and 64 bit libraries. Expected Results: links.
Created attachment 380816 [details] fix to gflags ebuild
Also, see #517134
Comment on attachment 380816 [details] fix to gflags ebuild --- gflags-2.1.1.ebuild 2014-07-15 18:28:14.805029210 +0200 +++ - 2014-07-16 16:02:47.758833654 +0200 @@ -4,7 +4,7 @@ EAPI="5" -inherit cmake-multilib +inherit cmake-multilib cmake-utils DESCRIPTION="Google's C++ argument parsing library" HOMEPAGE="http://code.google.com/p/gflags/" @@ -17,6 +17,12 @@ PATCHES=( "${FILESDIR}/gflags-2.1.1-libs.patch" ) +multilib_src_configure() { + local mycmakeargs=( -DBUILD_SHARED_LIBS=ON ) + + cmake-utils_src_configure +} + multilib_src_install_all() { rm -rf "${ED}"/usr/share/doc dodoc {AUTHORS,ChangeLog,NEWS,README}.txt
+*gflags-2.1.1-r1 (16 Jul 2014) + + 16 Jul 2014; Julian Ospald <hasufell@gentoo.org> -gflags-2.1.1.ebuild, + +gflags-2.1.1-r1.ebuild: + build shared libs wrt #517244, add static-libs USE flag
Just FYI: I did not enable shared libs because upstream doesn't seem to care about binary compatibility. The upgrade from 2.0 to 2.1.1 resulted in missing symbols in dev-util/open-vcdiff. I have since changed open-vcdiff to use a bundled copy of gflags; switched back to the system copy is on my to-do list.
(In reply to Mike Gilbert from comment #5) > Just FYI: I did not enable shared libs because upstream doesn't seem to care > about binary compatibility. > > The upgrade from 2.0 to 2.1.1 resulted in missing symbols in > dev-util/open-vcdiff. > > I have since changed open-vcdiff to use a bundled copy of gflags; switched > back to the system copy is on my to-do list. Is the SONAME really from upstream? If so, we should probably add a subslot too.
Yes, the SONAME is set by upstream, though not until after the 2.1.1 release was cut. https://code.google.com/p/gflags/source/detail?r=cd7aece14e2aac0669292c95ab42de6e267a5034
Also this. https://code.google.com/p/gflags/source/detail?r=bf889786c2a3a2dab89610d0722634d2eedfc694 Frankly, I think it would make more sense to keep the full package version as the SONAME; I think upstream has no clue as to how to version libraries.
(In reply to Mike Gilbert from comment #8) > Also this. > > https://code.google.com/p/gflags/source/ > detail?r=bf889786c2a3a2dab89610d0722634d2eedfc694 > > Frankly, I think it would make more sense to keep the full package version > as the SONAME; I think upstream has no clue as to how to version libraries. That seems to be common for google projects. Maybe someone should tell them.
https://code.google.com/p/gflags/issues/detail?id=85
(In reply to Mike Gilbert from comment #8) > Also this. > > https://code.google.com/p/gflags/source/ > detail?r=bf889786c2a3a2dab89610d0722634d2eedfc694 > > Frankly, I think it would make more sense to keep the full package version > as the SONAME; I think upstream has no clue as to how to version libraries. IMO, we should keep the upstream SONAME, file bugs for them whenever they break ABI and set our subslot to $PV, lol.
(In reply to Julian Ospald (hasufell) from comment #11) > IMO, we should keep the upstream SONAME, file bugs for them whenever they > break ABI and set our subslot to $PV, lol. That sounds reasonable.
I should have checked the issue tracker first. https://code.google.com/p/gflags/issues/detail?id=82 https://code.google.com/p/gflags/issues/detail?id=83 Need to review this and figure out how to sort out ebuild out.
*** Bug 517346 has been marked as a duplicate of this bug. ***
