The building result is like: $ ldd /localwork/benda/gentoo/usr/lib/libwx_gtk2u_core-2.8.so libgtk-x11-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libgtk-x11-2.0.so.0 (0x00002b95758eb000) libgdk-x11-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libgdk-x11-2.0.so.0 (0x00002b9575f2b000) libatk-1.0.so.0 => /localwork/benda/gentoo/usr/lib/libatk-1.0.so.0 (0x00002b95761e1000) libgio-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libgio-2.0.so.0 (0x00002b9576406000) libpangoft2-1.0.so.0 => /localwork/benda/gentoo/usr/lib/libpangoft2-1.0.so.0 (0x00002b9576748000) libgdk_pixbuf-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libgdk_pixbuf-2.0.so.0 (0x00002b9576976000) libpango-1.0.so.0 => /localwork/benda/gentoo/usr/lib/libpango-1.0.so.0 (0x00002b9576b98000) libfreetype.so.6 => /localwork/benda/gentoo/usr/lib/libfreetype.so.6 (0x00002b9576de5000) libfontconfig.so.1 => /localwork/benda/gentoo/usr/lib/libfontconfig.so.1 (0x00002b9577084000) libgobject-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libgobject-2.0.so.0 (0x00002b95772bc000) libgmodule-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libgmodule-2.0.so.0 (0x00002b957750d000) libgthread-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libgthread-2.0.so.0 (0x00002b9577711000) librt.so.1 => /lib64/librt.so.1 (0x00002b9577931000) libglib-2.0.so.0 => /localwork/benda/gentoo/usr/lib/libglib-2.0.so.0 (0x00002b9577b3a000) libXinerama.so.1 => /localwork/benda/gentoo/usr/lib/libXinerama.so.1 (0x00002b9577e5e000) libXxf86vm.so.1 => /localwork/benda/gentoo/usr/lib/libXxf86vm.so.1 (0x00002b9578062000) libSM.so.6 => /localwork/benda/gentoo/usr/lib/libSM.so.6 (0x00002b9578268000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002b9578471000) libz.so.1 => /localwork/benda/gentoo/lib/libz.so.1 (0x00002b9578696000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002b95788ae000) libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002b9578ad0000) libdl.so.2 => /lib64/libdl.so.2 (0x00002b9578d2b000) libwx_baseu-2.8.so.0 => /localwork/benda/gentoo/usr/lib/libwx_baseu-2.8.so.0 (0x00002b9578f2f000) libm.so.6 => /lib64/libm.so.6 (0x00002b957928c000) libstdc++.so.6 => /localwork/benda/gentoo/usr/x86_64-pc-linux-gnu/lib/gcc/libstdc++.so.6 (0x00002b9579510000) libgcc_s.so.1 => /localwork/benda/gentoo/lib/libgcc_s.so.1 (0x00002b9579819000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b9579a2f000) libc.so.6 => /lib64/libc.so.6 (0x00002b9579c4b000) libXext.so.6 => /localwork/benda/gentoo/usr/lib/libXext.so.6 (0x00002b9579fa2000) libXrender.so.1 => /localwork/benda/gentoo/usr/lib/libXrender.so.1 (0x00002b957a1b6000) libXi.so.6 => /localwork/benda/gentoo/usr/lib/libXi.so.6 (0x00002b957a3c2000) libXrandr.so.2 => /localwork/benda/gentoo/usr/lib/libXrandr.so.2 (0x00002b957a5d2000) libXcursor.so.1 => /localwork/benda/gentoo/usr/lib/libXcursor.so.1 (0x00002b957a7db000) libpangocairo-1.0.so.0 => /localwork/benda/gentoo/usr/lib/libpangocairo-1.0.so.0 (0x00002b957a9e7000) libX11.so.6 => /localwork/benda/gentoo/usr/lib/libX11.so.6 (0x00002b957abf5000) libXcomposite.so.1 => /localwork/benda/gentoo/usr/lib/libXcomposite.so.1 (0x00002b957af36000) libXdamage.so.1 => /localwork/benda/gentoo/usr/lib/libXdamage.so.1 (0x00002b957b13b000) libXfixes.so.3 => /localwork/benda/gentoo/usr/lib/libXfixes.so.3 (0x00002b957b33e000) libcairo.so.2 => /localwork/benda/gentoo/usr/lib/libcairo.so.2 (0x00002b957b545000) libbz2.so.1 => /localwork/benda/gentoo/lib/libbz2.so.1 (0x00002b957b7f8000) libexpat.so.1 => /localwork/benda/gentoo/usr/lib/libexpat.so.1 (0x00002b957ba08000) libffi.so.5 => /localwork/benda/gentoo/usr/lib/libffi.so.5 (0x00002b957bc34000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b957be3d000) libpng15.so.15 => /localwork/benda/gentoo/usr/lib/libpng15.so.15 (0x00002b957c053000) /lib64/ld-linux-x86-64.so.2 (0x0000003ad8e00000) libICE.so.6 => /localwork/benda/gentoo/usr/lib/libICE.so.6 (0x00002b957c281000) libuuid.so.1 => /localwork/benda/gentoo/lib/libuuid.so.1 (0x00002b957c49f000) libxcb.so.1 => /localwork/benda/gentoo/usr/lib/libxcb.so.1 (0x00002b957c6a5000) libpixman-1.so.0 => /localwork/benda/gentoo/usr/lib/libpixman-1.so.0 (0x00002b957c8c4000) libXau.so.6 => /localwork/benda/gentoo/usr/lib/libXau.so.6 (0x00002b957cb4d000) libXdmcp.so.6 => /localwork/benda/gentoo/usr/lib/libXdmcp.so.6 (0x00002b957cd52000) causing wxGTK segment fault at runtime. The libraries seems to come from configure.in: *-*-linux* ) dnl use ../lib or ../lib64 depending on the size of void* if test "$ac_cv_sizeof_void_p" = 8 -a \ -d "/usr/lib64" -a ! -h "/usr/lib64"; then wx_cv_std_libpath="lib64" else wx_cv_std_libpath="lib" fi ;; and SEARCH_LIB="`echo "$SEARCH_INCLUDE" | sed s@include@$wx_cv_std_libpath@g` /usr/$wx_cv_std_libpath" Reproducible: Always
Created attachment 295299 [details, diff] let wxGTK link against prefix libraries for amd64-linux
Adding Ryan to Cc List, Hi Ryan, I have made some non-trivial modifications to the ebuild to let configure search for ${EPREFIX}/usr/{include,lib} first. I have (unfortunately) spent quite some time on bakefile. It turns out bakefile-0.2.8 just fails (weird, maybe some files should be deleted before bakefile_gen) and bakefile-0.2.9 succeeded. (yes, I'd file a bug to bump bakefile) I suggest we regenerate configure and Makefile.in as shown in my patch to make prefix and gentoo-x86 consistent. Another reason for regenerating with bakefile is that wxGTK-2.8.11-collision.patch is applied against Makefile.in, which is auto-generated by bakefile. It would be better if we patch build/bakefiles/wx.bkl. What do you think, Ryan? Yours, Benda
I'd rather not have to depend on bakefile getting things right, especially if minor version bumps are going to break things. Can you patch configure.in to not do stupid stuff like the above?
(In reply to comment #3) > I'd rather not have to depend on bakefile getting things right, especially if > minor version bumps are going to break things. running eautoreconf from autoconf.eclass for patching broken build systems becomes quite common in gentoo now. There should be not much difference between eautoreconf and "bakefile_gen && eautoconf". The two practices would have the same chance to (un)break things across minor version bumps. > Can you patch configure.in to not do stupid stuff like the above? The two seds interpret to 'replace SEARCH_INCLUDE="whatever" with SEARCH_INCLUDE="${EPREFIX}/usr/include', and replace '/usr' with '${EPREFIX}/usr'. These modifications is easier to maintain with sed than a patch across version bumps. ====== I wish I could just patch configure.in and just do a eautoconf. The problem is, for files shipped with 2.8.12.1, ${S}/build/aclocal/bakefile.m4 (which is included by aclocal.m4) is generated with bakefile 0.2.8: ./build/aclocal/bakefile.m4:840: BAKEFILE_BAKEFILE_M4_VERSION="0.2.8" But ${S}/autoconf_inc.m4 is from bakefile 0.2.9: ./autoconf_inc.m4:7:BAKEFILE_AUTOCONF_INC_M4_VERSION="0.2.9" Doing eautoconf -B build/autoconf_prepend-include will end up with a configure failing with: configure: error: Versions of Bakefile used to generate makefiles (0.2.9) and configure (0.2.8) do not match. That's why in order to regenerate the configure, we have to go through bakefile the align all the m4 to a consistent version. We could just copy m4 from bakefile-0.2.9 to ./build/aclocal without running bakefile_gen. But this is easier to fail than copy and regenerate when version bumps. ====== Ok, I finally realized I could file a bug to upstream NOT to ship version inconsistent m4 macros in their release to avoid bakefile_gen.
upstream ticket for reference: http://trac.wxwidgets.org/ticket/13743
(In reply to comment #4) > running eautoreconf from autoconf.eclass for patching broken build systems > becomes quite common in gentoo now. There should be not much difference between > eautoreconf and "bakefile_gen && eautoconf". The two practices would have the > same chance to (un)break things across minor version bumps. One of these things is used to build the majority of software packages in the tree, is well supported, and any incompatibilities will be flushed out immediately, documented, and fixed. The other is bakefile. :) > > Can you patch configure.in to not do stupid stuff like the above? > > The two seds interpret to 'replace SEARCH_INCLUDE="whatever" with > SEARCH_INCLUDE="${EPREFIX}/usr/include', and replace '/usr' with > '${EPREFIX}/usr'. These modifications is easier to maintain with sed than a > patch across version bumps. Sorry, I didn't mean "patch" literally. I meant "do the sed directly to configure.in", but now I notice that's in fact what you're doing. > I wish I could just patch configure.in and just do a eautoconf. The problem is, > for files shipped with 2.8.12.1, ${S}/build/aclocal/bakefile.m4 (which is > included by aclocal.m4) is generated with bakefile 0.2.8: > > ./build/aclocal/bakefile.m4:840: BAKEFILE_BAKEFILE_M4_VERSION="0.2.8" > > But ${S}/autoconf_inc.m4 is from bakefile 0.2.9: > > ./autoconf_inc.m4:7:BAKEFILE_AUTOCONF_INC_M4_VERSION="0.2.9" > > Doing eautoconf -B build/autoconf_prepend-include will end up with a configure > failing with: > > configure: error: Versions of Bakefile used to generate makefiles (0.2.9) > and configure (0.2.8) do not match. > > That's why in order to regenerate the configure, we have to go through bakefile > the align all the m4 to a consistent version. We could just copy m4 from > bakefile-0.2.9 to ./build/aclocal without running bakefile_gen. But this is > easier to fail than copy and regenerate when version bumps. These are the types of minor version issues I was worried about. My last attempt to use bakefile ran into similar problems, but perhaps I was doing it wrong. If your approach avoids these then maybe we can consider it. But the fact that bakefile-0.2.8 fails doesn't fill me with confidence. Maybe it's a fluke, but we really can't get into a situation where different wxGTK SLOTs only work with specific, conflicting versions of bakefile. I'd like to see some testing of 2.8.11 and 2.9 with different bakefile versions.
(In reply to comment #6) > One of these things is used to build the majority of software packages in the > tree, is well supported, and any incompatibilities will be flushed out > immediately, documented, and fixed. The other is bakefile. :) Yeah, I agree with you. > These are the types of minor version issues I was worried about. My last > attempt to use bakefile ran into similar problems, but perhaps I was doing it > wrong. If your approach avoids these then maybe we can consider it. But the > fact that bakefile-0.2.8 fails doesn't fill me with confidence. Maybe it's a > fluke, but we really can't get into a situation where different wxGTK SLOTs > only work with specific, conflicting versions of bakefile. I'd like to see > some testing of 2.8.11 and 2.9 with different bakefile versions. I tried bakefile-0.2.8 again. configure can not figure out it is using gcc and disables -fPIC, causing the final linking failure. I agree that depending on minor versions of a build tool is a headache :( Upstream has synchronized the m4 macros to the same bakefile version. Maybe we can just leave it alone and wait for the change propagates to wxPython to do the patch in configure.in and just run autoconf. For this bug only affects Prefix users, I could keep the dirty things inside Prefix tree (or just at my own overlay if grobian does not agree) before we finally resolve it.
Can you simply sed configure and avoid the autoconf?
Created attachment 314675 [details, diff] wxGTK.patch This one patches against only configure
Created attachment 314677 [details, diff] wxGTK.path patches only against configure. Ryan, please review. thanks.
Created attachment 314679 [details, diff] wxGTK.patch sorry, I forgot to pass extra parameter to diff
Hey, I bet this patch is minimal enough to get included. and the behavior of the build system is well understood. If there is no objections, I will commit this in a week.
Ok.
Wait, not okay if this is what's causing bug #420247.
It is. [ebuild R ] x11-libs/wxGTK-2.8.12.1::tundra [2.8.12.1::gentoo] USE="X gstreamer opengl sdl tiff (-aqua) -debug -doc -gnome -odbc -pch" 0 kB /var/tmp/portage/x11-libs/wxGTK-2.8.12.1/work/wxPython-src-2.8.12.1/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-dependency-tracking --enable-compat26 --enable-shared --enable-unicode --with-regex=builtin --with-zlib=sys --with-expat=sys --disable-debug --disable-precomp-headers --without-odbc --with-sdl --with-libtiff=sys --enable-graphics_ctx --enable-gui --with-libpng=sys --with-libxpm=sys --with-libjpeg=sys --enable-mediactrl --enable-opengl --with-opengl=""/usr --without-gnomeprint --without-gnomevfs checking for --with-opengl... no
Created attachment 315057 [details, diff] wxGTK.patch new patch with good opengl handling
Hi, Ryan, sorry for the trouble. Could you please review the new patch? I have tested against wxpython[opengl].
+ -e "s:/usr:${EPREFIX}/usr:g" \ + -e '/SEARCH_INCLUDE="\\/,/"/cSEARCH_INCLUDE="'${EPREFIX}'/usr/include"' \ I think the first line can break commands if the EPREFIX path contains spaces. I'd also like to do a diff with and without this patch to make sure it doesn't affect anything it shouldn't. Give me few days.
I think this is a bit invasive. But it doesn't seem to break anything here, so if there's no other option then I guess you can go ahead.
committed Prefix patch only, as opengl one is addressed in bug 443684. + 04 Feb 2013; Benda Xu <heroxbd@gentoo.org> wxGTK-2.8.12.1.ebuild: + fix Prefix library location in configure. bug 394123 +
