I ran into a build problem for gnuplot, but since I'm trying to build on a Mac, none of the usual fixes work. There's no revdep-rebuild ad no lafilefixer. Thus, what we find here doesn't help me: https://bugs.gentoo.org/show_bug.cgi?id=319101 The error I'm getting when emerging gnuplot is this: x86_64-apple-darwin10-g++ -O2 -pipe -ggdb -march=core2 -ggdb -Wl,-dead_strip_dylibs -L/Users/millerti/Gentoo/usr/lib -Wl,-dead_strip_dylibs -L/usr/X11/lib -o gnuplot alloc.o axis.o binary.o breaders.o bitmap.o color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o gp_cairo.o gp_cairo_helpers.o -lreadline -lncurses -lz -lgd -ljpeg -lpng14 -lz /Users/millerti/Gentoo/usr/lib/libiconv.dylib -ljpeg -L/Users/millerti/Gentoo/usr/lib -lz -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl ld: library not found for -lpng14 I tried emerging the latest 1.4.x version of libpng, but that doesn't work either. Although the library is there: $ ls -l ~/Gentoo/usr/lib/*png* lrwxrwxrwx 1 millerti staff 14 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng.dylib -> libpng15.dylib -rwxr-xr-x 1 millerti staff 210656 Sep 22 17:10 /Users/millerti/Gentoo/usr/lib/libpng14.14.dylib -rwxr-xr-x 1 millerti staff 235312 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng15.15.4.0.dylib lrwxrwxrwx 1 millerti staff 21 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng15.15.dylib -> libpng15.15.4.0.dylib lrwxrwxrwx 1 millerti staff 21 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng15.dylib -> libpng15.15.4.0.dylib Finally, I tried this, and then gnuplot would emerge: ln -s libpng14.14.dylib libpng14.dylib Of course, now I don't have a build.log or enrivonment for you, because now gnuplot installed. But in any case, we see the problem, which is that libpng1.4.8 didn't install a symlink. Reproducible: Always Portage 2.2.01.19295-prefix (prefix/darwin/macos/10.6/x64, gcc-4.2.1, unavailable, 11.1.0 x86_64) ================================================================= System uname: Darwin-11.1.0-x86_64-i386-64bit Timestamp of tree: Thu, 22 Sep 2011 20:40:20 +0000 distcc 3.1-toolwhip.1 i386-apple-darwin11.0 [disabled] app-shells/bash: 4.2_p10 dev-lang/python: 2.7.2 dev-util/pkgconfig: 0.25-r2 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1 sys-devel/gcc-config: 1.4.1-r00.2 sys-devel/libtool: 2.4-r01.1 sys-devel/make: 3.82 Repositories: gentoo_prefix Installed sets: ACCEPT_KEYWORDS="~x64-macos" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-apple-darwin10" CFLAGS="-O2 -pipe -ggdb -march=core2 -ggdb" CHOST="x86_64-apple-darwin10" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/portage /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe -ggdb -march=core2 -ggdb" DISTDIR="/Users/millerti/Gentoo/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--jobs=2" FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles fixpackages news nostrip parallel-fetch preserve-libs protect-owned sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-dead_strip_dylibs" LINGUAS="en en_US" MAKEOPTS="--jobs=8" PKGDIR="/Users/millerti/Gentoo/usr/portage/packages" PORTAGE_CONFIGROOT="/Users/millerti/Gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/Users/millerti/Gentoo/var/tmp" PORTDIR="/Users/millerti/Gentoo/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="aqua cairo coreaudio cracklib cxx ithreads jpeg mmx mmxext modules ncurses nls nptl objc objc++ pdf png prefix readline sse sse2 ssl threads tiff unicode x64-macos zlib" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="Darwin" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="Darwin" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Latest 1.4 doesn't install the symlink, cause it's for binary-only packages. Once 1.5 was released into unstable, that the one that should be used. You need to check why it's not getting picked up.
I did some googling on this. I found this, for instance: http://newsgroups.derkeiler.com/Archive/Comp/comp.graphics.apps.gnuplot/2011-01/msg00011.html It looks like gnuplot explicitly asks for libpng 1.4. This has caused trouble for many people on many platforms. I'm guessing there are enough differences between libpng 1.2 and 1.4 that they had to special-case 1.4, and that special case doesn't account for 1.5. For us, that's gnuplot bug. Here's another link: http://lists.macosforge.org/pipermail/macports-users/2011-January/023178.html The current release of gnuplot is 4.4.3. We may want to check out the CVS head, which is version 4.5. I've done a little searching on gnuplot's tracker, and I don't see any mention of libpng, however, at least not anything recent.
Upstream bug report: https://sourceforge.net/tracker/?func=detail&aid=3413082&group_id=2055&atid=102055
Portage had a bug which prevents preserve-libs from working. At that time, libpng was bumped. Can you try emerge -1 =libpng-1.4.8 followed by emerge -1u libpng? Make sure your tree is synced, and that you have the latest portage installed. Portage should report libpng14 to be preserved after emerging libpng-1.5. Run emerge @preserved-rebuild as suggested by Portage. It will probably rebuild cairo, which gnuplot uses these days. I think gnuplot is built by libtool, but you didn't copy that piece, where I think you can see libtool linking to cairo.la, which contains the libpng14 reference. Anyhow, just make sure portage updates all packages, such that libpng14.dylib is removed due to "!needed".
Another duplicate of bug 319101 with a twist, feel free to dupe.
I don't consider it a dupe, since preserve-libs was broken on Darwin, which would have remedied the problem if it would've worked.
(In reply to comment #6) > I don't consider it a dupe, since preserve-libs was broken on Darwin, which > would have remedied the problem if it would've worked. "ld: library not found for -lpng14" looks like it's coming from broken libtool archive (.la) looking for libpng14.so which wouldn't have preserved by preserved-libs in any case since it's not the actual SONAME so with that said, it's a duplicate
fine, but since a user should run emerge @preserved-rebuild first the libtool archive would get updated (or removed, and thereby breaking a random amount of other packages)
I had tried "emerge -1 =libpng-1.4.8", but that didn't work, as I mentioned before, until I manually made a symlink in .../Gentoo/usr/lib. Before that I had tried "emerge @preserved-rebuild", but that didn't do anything to fix this problem.
please clarify "that didn't work"
Emerging libpng-1.4.8 itself worked just fine. However, emerging gnuplot still failed with it being unable to find -lpng14. Once I made the symlink, then gnuplot linked just fine. However, someone else said that libpng-1.4.8 isn't supposed to install a symlink because that's only for binary packages. Here's what I have now: lrwxrwxrwx 1 millerti staff 14 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng.dylib -> libpng15.dylib -rwxr-xr-x 1 millerti staff 210656 Sep 22 17:10 /Users/millerti/Gentoo/usr/lib/libpng14.14.dylib lrwxr-xr-x 1 millerti staff 17 Sep 22 17:16 /Users/millerti/Gentoo/usr/lib/libpng14.dylib -> libpng14.14.dylib -rwxr-xr-x 1 millerti staff 235312 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng15.15.4.0.dylib lrwxrwxrwx 1 millerti staff 21 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng15.15.dylib -> libpng15.15.4.0.dylib lrwxrwxrwx 1 millerti staff 21 Sep 22 17:02 /Users/millerti/Gentoo/usr/lib/libpng15.dylib -> libpng15.15.4.0.dylib And I added libpng14.dylib manually.
That's 1.4.8-r1 IMO, 1.4.8 still installs the full bunch. let me repeat that installing libpng whichever version doesn't solve this problem, but the @preserved-rebuild should
(In reply to comment #12) > That's 1.4.8-r1 IMO, 1.4.8 still installs the full bunch. Both 1.4.8 and 1.4.8-r1 install full bunch, 1.4.8-r2 doesn't, it's the SLOTed one. > let me repeat that installing libpng whichever version doesn't solve this > problem, but the @preserved-rebuild should The symlink to eg. libpng14.so does not get preserved in any case, but the SONAME eg. libpng14.so.14 does. Therefore the linker does NOT find -lpng14 in any case, with or without preserved-libs. In fact, the more I think of it, preserved-libs has nothing to do with this bug...
*** This bug has been marked as a duplicate of bug 319101 ***
(In reply to comment #13) > > let me repeat that installing libpng whichever version doesn't solve this > > problem, but the @preserved-rebuild should > > The symlink to eg. libpng14.so does not get preserved in any case, but the > SONAME eg. libpng14.so.14 does. Therefore the linker does NOT find -lpng14 in > any case, with or without preserved-libs. In fact, the more I think of it, > preserved-libs has nothing to do with this bug... Your logic is flawed, given the critical information provided in this bug.
(In reply to comment #15) > (In reply to comment #13) > > > let me repeat that installing libpng whichever version doesn't solve this > > > problem, but the @preserved-rebuild should > > > > The symlink to eg. libpng14.so does not get preserved in any case, but the > > SONAME eg. libpng14.so.14 does. Therefore the linker does NOT find -lpng14 in > > any case, with or without preserved-libs. In fact, the more I think of it, > > preserved-libs has nothing to do with this bug... > > Your logic is flawed, given the critical information provided in this bug. If one of libraries was linked against libpng14 that gnuplot is trying to link against, and the library was missing, wouldn't the error show up as "Undefined reference" -styled instead of "ld: library not found for -lpng14" ? The linker is in fact looking for the symlink, not the soname, which is not preserved. So given all the facts provided in this bug, it's still a dupe.
(In reply to comment #16) > > Your logic is flawed, given the critical information provided in this bug. > > If one of libraries was linked against libpng14 that gnuplot is trying to link > against, and the library was missing, wouldn't the error show up as "Undefined > reference" -styled instead of "ld: library not found for -lpng14" ? The linker > is in fact looking for the symlink, not the soname, which is not preserved. > So given all the facts provided in this bug, it's still a dupe. Yes, but this is not the issue in this bug. This is Darwin, and I know I screwed it up on Darwin. Of course you understand the implications of sonames, libtool archives, running and linking. However, for me, this bug is dealing with a problem one step before all of that, introduced by a screwup in Portage on Darwin platforms.
(In reply to comment #17) > Yes, but this is not the issue in this bug. This is Darwin, and I know I > screwed it up on Darwin. Of course you understand the implications of sonames, > libtool archives, running and linking. However, for me, this bug is dealing > with a problem one step before all of that, introduced by a screwup in Portage > on Darwin platforms. OK, let's fix the $summary then since we are not talking about the error posted on the bug anymore.
I think this was fixed by a gnuplot upgrade
