Summary: | =media-gfx/graphviz-2.26.3-r2 fails to compile with sys-devel/libtool-2.4 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Samuli Suominen (RETIRED) <ssuominen> |
Component: | Current packages | Assignee: | Gentoo Graphics Project <graphics+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | atswartz, blueness, cedric.godin, crazy-ivanovic, cuciferus, david+gentoo.org, fkrogh, holger, krinpaus, naota, polynomial-c, robi.k, zioalex |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.graphviz.org/bugs/b2050.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 347427 | ||
Attachments: |
build.log
Make *sure* only system copy is used For prev. attached ebuild gvcext.h conflicts w/ /usr/include/ltdl.h |
Description
Samuli Suominen (RETIRED)
![]() Created attachment 249121 [details]
build.log
I believe I have this bug fixed in the upstream graphviz sources. cvs diff -r1.116 -r1.117 lib/gvc/Makefile.am Basically, $(INCLTDL) is sufficient, and -I$(top_srcdir)/libltdl causes the problem: @@ -18,8 +18,7 @@ -I$(top_srcdir)/lib/pathplan \ -I$(top_srcdir)/lib/$(GRAPH) \ -I$(top_srcdir)/lib/cdt \ - $(INCLTDL) -I$(top_srcdir)/libltdl \ - -DGVLIBDIR=\"$(pkglibdir)\" + $(INCLTDL) -DGVLIBDIR=\"$(pkglibdir)\" if WITH_WIN32 AM_CFLAGS = -D_BLD_gvc=1 (In reply to comment #2) > I believe I have this bug fixed in the upstream graphviz sources. To put that in one-liner sed: sed -i -e 's:-I$(top_srcdir)/libltdl::' lib/gvc/Makefile.am || die #339298 in src_prepare() of the ebuild It doesn't solve the issue. It looks like the ebuild is already going great lenghts to avoid using the internal copy already, before this bug: # This is an old version of libtool rm -rf libltdl sed -i -e '/libltdl/d' configure.ac || die sed -i -e 's/AC_LIBLTDL_CONVENIENCE/AC_LIBLTDL_INSTALLABLE/' configure.ac || die And then runs eautoreconf on the package, which seems to create the libltdl directory again... sigh. Configures the package with --disable-ltdl-install to avoid the package to install the bundled libltdl to system, then --enable-ltdl to enable ltdl for use. What a mess... Created attachment 249672 [details, diff]
Make *sure* only system copy is used
This with next attachment -libtool.patch will ensure only *system* copy is used, and it still fails with:
In file included from ../../lib/common/types.h:36:0,
from gvplugin.c:27:
./gvcext.h:83:22: error: conflicting types for 'lt__PROGRAM__LTX_preloaded_symbols'
/usr/include/ltdl.h:106:36: note: previous declaration of 'lt__PROGRAM__LTX_preloaded_symbols' was here
(I'm not suggesting to use this in Portage, only making a point that the error happens regardless. There's something wrong in gvcext.h itself with libtool-2.4, imho.)
Created attachment 249673 [details, diff]
For prev. attached ebuild
Created attachment 254443 [details, diff]
gvcext.h conflicts w/ /usr/include/ltdl.h
You have missed that one :)
Graphviz did not build for me on my ~x86 laptop until I used Samuli's patches AND Jimmy Jazz's patch together. I hope this helps. (In reply to comment #2) > I believe I have this bug fixed in the upstream graphviz sources. > > cvs diff -r1.116 -r1.117 lib/gvc/Makefile.am > > Basically, $(INCLTDL) is sufficient, and -I$(top_srcdir)/libltdl causes the > problem: > > @@ -18,8 +18,7 @@ > -I$(top_srcdir)/lib/pathplan \ > -I$(top_srcdir)/lib/$(GRAPH) \ > -I$(top_srcdir)/lib/cdt \ > - $(INCLTDL) -I$(top_srcdir)/libltdl \ > - -DGVLIBDIR=\"$(pkglibdir)\" > + $(INCLTDL) -DGVLIBDIR=\"$(pkglibdir)\" > > if WITH_WIN32 > AM_CFLAGS = -D_BLD_gvc=1 > I've included this change, plus the change from Comment #6 and it seems to work now. +*graphviz-2.26.3-r3 (17 Nov 2010) + + 17 Nov 2010; Samuli Suominen <ssuominen@gentoo.org> + +graphviz-2.26.3-r3.ebuild, +files/graphviz-2.26.3-libtool.patch: + Fix building with libtool >= 2.4 wrt #339298 by John Ellson and Jimmy + Jazz. *** Bug 346943 has been marked as a duplicate of this bug. *** *** Bug 349153 has been marked as a duplicate of this bug. *** *** Bug 376029 has been marked as a duplicate of this bug. *** |