Re: Heads up: libpng bumped to 1.5.x in rawhide
On Sun, 06 Nov 2011 17:56:40 +0200, VS (Ville) wrote:
Puzzles me. The F-16 build doesn't depend on libpng* directly:
$ rpm -qR geeqie|grep png
$ rpm -q geeqie
geeqie-1.0-13.fc16.x86_64
I noticed a similar thing with gkrellm-volume -- the F-15 build did have
a dependency on it, but the F-16 one didn't (libm was similarly gone,
maybe some others too). I suppose some pkg-config files of the build
dependency chain no longer had those in pkg-config --libs output on F-16
but did on F-15.
At least -lpng12 is gone in several build logs.
Anyway, applying -Wl,--as-needed on a new Rawhide gkrellm-volume build
still got rid of quite a few additional unnecessary deps even though it
would no longer have been necessary in order to get rid of the libpng one.
Two findings after I tested a bit on Sunday:
* Some programs insert LDFLAGS after LIBS. This works for appending
libraries from within the spec file (such as -lm), but linker options
like --as-needed only affect libraries following it.
* The %configure macro (at least since F-16) does
LDFLAGS=${LDFLAGS:--Wl,-z,relro }; export LDFLAGS;
so one cannot simply export a customized $LDFLAGS in the spec file
without disturbing the macro.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On 11/07/2011 10:35 AM, Ville Skyttä wrote:
On 11/07/2011 01:57 PM, Michael Schwendt wrote:
* The %configure macro (at least since F-16) does
LDFLAGS=${LDFLAGS:--Wl,-z,relro }; export LDFLAGS;
so one cannot simply export a customized $LDFLAGS in the spec file
without disturbing the macro.
That's what I meant by (in addition to RPM_LD_FLAGS) in my first mail
to this thread. It should be done for example like this:
%build
export LDFLAGS=$RPM_LD_FLAGS -Wl,--as-needed
%configure [...]
On my F-16 box. %configure is running:
LDFLAGS=${LDFLAGS:--Wl,-z,relro }; export LDFLAGS;
If we really want -Wl,--as-needed, it should be simple enough to add to
the %configure definition. Playing with nacl in chromium has reminded me
that I'm definitely not a toolchain guru, but what would the downside be
of making that macro change system-wide (in rawhide) ?
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote: twaugh ghostscript twaugh gutenprint I've rebuilt these two. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On 11/07/2011 12:16 PM, Tim Waugh wrote: On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote: twaugh ghostscript twaugh gutenprint I've rebuilt these two. Tim. */ (Apologies for replying to your reply, Tim, but I wasn't subscribed at the start of this thread.) I'm a graphviz upstream maintainer, not a fedora maintainer, so these changes have not been applied yet: I verified that graphviz can be built locally with libpng15, after: - rebuilding gd - no changes needed - rebuilding gdk_pixbuf2 - no changes needed - rebuilding DevIL - needed patch https://bugzilla.redhat.com/show_bug.cgi?id=751583 - rebuilding graphviz - needed patch https://bugzilla.redhat.com/show_bug.cgi?id=751807 The graphviz changes were due to changes in PHP's abi, rather than libpng15. The PHP abi problem also affects fc16. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On Mon, 07 Nov 2011 17:35:53 +0200, VS (Ville) wrote:
* The %configure macro (at least since F-16) does
LDFLAGS=${LDFLAGS:--Wl,-z,relro }; export LDFLAGS;
so one cannot simply export a customized $LDFLAGS in the spec file
without disturbing the macro.
That's what I meant by (in addition to RPM_LD_FLAGS) in my first mail
to this thread. It should be done for example like this:
%build
export LDFLAGS=$RPM_LD_FLAGS -Wl,--as-needed
%configure [...]
Good info.
That's based on some background:
RPM_LD_FLAGS=%{?__global_ldflags}
$ rpm --eval %__global_ldflags
-Wl,-z,relro
Aha! :)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On Sat, 2011-11-05 at 13:02 -0400, Tom Lane wrote: pgordon glabels pgordon lucidlife Thanks for the FYI email. I rebuilt both of these yesterday with no problems and no source changes necessary. Regards. -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On Sat, 05 Nov 2011 19:35:21 -0400, TL (Tom) wrote: On Sat, 05 Nov 2011 19:07:44 -0400, TL (Tom) wrote: My list was just the result of repoquery --whatrequires. The last Rawhide build of geeqie also doesn't depend on libpng*. F-15 does, however, which might be where you've run repoquery. Hmm ... actually I did it on an F-14 box. My notes say I did repoquery --repoid=fedora-rawhide --whatrequires ... but I've had problems before with repoquery not doing what I thought it would. Can anyone elucidate on the proper incantation for this? Well, the basic options are correct [--alldeps is the default, and the --repoid option disables all repos but the specified one(s)]. However, the repoid is suspicous. On F-14, the fedora-release-rawhide package installs a fedora-rawhide.repo file for a rawhide repo not a fedora-rawhide repo. You could verify whether your fedora-rawhide is not a custom one pointing at something other than the true Rawhide. Running this same query (also on F-14), geeqie isn't in the output but many many packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On 11/06/2011 12:26 AM, Michael Schwendt wrote: Puzzles me. The F-16 build doesn't depend on libpng* directly: $ rpm -qR geeqie|grep png $ rpm -q geeqie geeqie-1.0-13.fc16.x86_64 I noticed a similar thing with gkrellm-volume -- the F-15 build did have a dependency on it, but the F-16 one didn't (libm was similarly gone, maybe some others too). I suppose some pkg-config files of the build dependency chain no longer had those in pkg-config --libs output on F-16 but did on F-15. Anyway, applying -Wl,--as-needed on a new Rawhide gkrellm-volume build still got rid of quite a few additional unnecessary deps even though it would no longer have been necessary in order to get rid of the libpng one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: libpng bumped to 1.5.x in rawhide
The list of packages that need to be rebuilt is attached. I'm not too sure about ordering dependencies, but I do know that gd and libsexy need to be rebuilt before some of the others. Some of these packages will require source code changes. See yesterday's discussion for hints about where to find patches. (Sorry for not being more verbose, but I've got to leave shortly. If you need help, ask me off-list.) regards, tom lane (orphan) amide (orphan) assogiate (orphan) emerald (orphan) gconf-cleaner (orphan) geda-gattrib (orphan) geda-gnetlist (orphan) geda-gschem (orphan) geda-gsymcheck (orphan) geda-utils (orphan) giggle (orphan) gpx-viewer (orphan) grfcodec (orphan) libgeda (orphan) python-gpod (orphan) slim (orphan) xfce4-dict-plugin (orphan) xfce4-screenshooter-plugin abo java-gnome abompard grisbi adalloz pan adamwill bamf adamwill libindicator adrian bwbar adrian fbida adrian gmpc adrian grip adrian sopwith affix cssed agoode gkrellm-weather agoode nip2 agoode vips ajax wayland alexlan mapnik als fpm2 ankursinha aeskulap ankursinha xmedcon athimm nx athimm synaptic athimm vtk avesh NetworkManager-openswan awjb WindowMaker awjb airsnort awjb aterm awjb dillo awjb dosbox awjb fbdesk awjb gimmix awjb multisync awjb perl-Tk awjb qiv awjb rxvt-unicode awjb synce-software-manager awjb synce-trayicon balajig8 thunarx-python behdad libgnomeprintui22 behdad vte belegdol gnome-chemistry-utils bellet FlightGear-Atlas berrange autobuild-applet berrange entangle berrange gtk-vnc berrange virt-viewer bjohnson goocanvas bjohnson pygoocanvas bogado puzzles bogado raw-thumbnailer bouska gtkperf bpepple nautilus-image-converter bpepple telepathy-stream-engine bpostle enblend bpostle hugin bpostle libpano12 bpostle libpano13 bpostle vigra brouhaha free42 bruno gdk-pixbuf bruno ggz-gtk-client bruno gnubik bruno greyhounds bruno lordsawar bruno sirius bsjones guitarix bsjones gx_head bsjones jamin bsjones lv2-ll-plugins bsjones phat buc dvdisaster buc gnome-translate buc gtk-gnutella buc mail-notification buc xawtv cagney libgconf-java cagney libglade-java cagney libgnome-java cagney libgtk-java cagney libvte-java caillon drwright caillon gnome-hearts caillon xchat candyz gcin caolanm libwmf caolanm planner carllibpst ghemical cassmodiah fife cassmodiah florence cassmodiah gnaughty cassmodiah surf cheese teg chitlesh fped chitlesh gerbv chitlesh kshutdown chitlesh linsmith chitlesh pcb chitlesh pikloops chkr f-spot chkr gnome-do chkr gthumb chkr nall company cairo company gstreamer-plugins-bad-free company gstreamer-plugins-good corsepiu k3d cosimoc the-board cweyl perl-Gnome2 cweyl perl-Gnome2-Canvas cweyl perl-Gnome2-Print cweyl perl-Gtk2-GladeXML cweyl perl-Gtk2-Notify cweyl perl-Gtk2-Sexy cweyl perl-Gtk2-Spell cweyl perl-Gtk2-TrayIcon cwickert beldi cwickert fbpanel cwickert glista cwickert gnome-applet-alarm-clock cwickert gpicview cwickert gpp cwickert grsync cwickert gtkhash cwickert gtrayicon cwickert gwget cwickert gxmessage cwickert ignuit cwickert leafpad cwickert libxfce4ui cwickert lilyterm cwickert lostirc cwickert lxappearance cwickert lxdm cwickert lxinput cwickert lxlauncher cwickert lxmusic cwickert lxpanel cwickert lxpolkit cwickert lxrandr cwickert lxsession cwickert lxsession-edit cwickert lxshortcut cwickert lxtask cwickert lxterminal cwickert mypaint cwickert osmo cwickert parcellite cwickert parole cwickert pnmixer cwickert regexxer cwickert remmina cwickert ristretto cwickert sakura cwickert termit cwickert thunar-media-tags-plugin cwickert thunar-vfs cwickert tumbler cwickert viewnior cwickert volumeicon cwickert xarchiver cwickert xfbib cwickert xfburn cwickert xfce4-battery-plugin cwickert xfce4-cellmodem-plugin cwickert xfce4-clipman-plugin cwickert xfce4-cpugraph-plugin cwickert xfce4-datetime-plugin cwickert xfce4-dict cwickert xfce4-diskperf-plugin cwickert xfce4-eyes-plugin cwickert xfce4-fsguard-plugin cwickert xfce4-genmon-plugin cwickert xfce4-mailwatch-plugin cwickert xfce4-modemlights-plugin cwickert xfce4-mount-plugin cwickert xfce4-mpc-plugin cwickert xfce4-netload-plugin cwickert xfce4-notes-plugin cwickert xfce4-notifyd cwickert xfce4-places-plugin cwickert xfce4-power-manager cwickert xfce4-quicklauncher-plugin cwickert xfce4-radio-plugin cwickert xfce4-screenshooter cwickert xfce4-sensors-plugin cwickert xfce4-smartbookmark-plugin cwickert xfce4-systemload-plugin cwickert xfce4-taskmanager cwickert xfce4-timer-plugin cwickert xfce4-verve-plugin cwickert xfce4-volumed cwickert xfce4-wavelan-plugin cwickert xfce4-weather-plugin cwickert xfce4-websearch-plugin cwickert xfce4-xfswitch-plugin cwickert xfce4-xkb-plugin cwickert xfmpc cwickert xpad davidcornette lv2-EQ10Q-plugins davidcornette lv2-invada-plugins davidz dasher davidz
Re: Heads up: libpng bumped to 1.5.x in rawhide
This is my first time as a contributor to run into this. Do I simply need to increment by release by 1 (or .1?) and build? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
If it is a new version from upstream then the release will be 1 but if you are updating the SPEC file you would increment the release number. On Sat, Nov 5, 2011 at 12:20 PM, Richard Shaw hobbes1...@gmail.com wrote: This is my first time as a contributor to run into this. Do I simply need to increment by release by 1 (or .1?) and build? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On 11/05/2011 07:02 PM, Tom Lane wrote: The list of packages that need to be rebuilt is attached. I suggest maintainers take this opportunity to review whether all these packages really need to be linked against libpng - I'm positive that the list contains a lot of packages that don't. -Wl,--as-needed in LDFLAGS (in addition to RPM_LD_FLAGS) is one easy way that can be applied in many cases to get rid of unnecessary linkage bloat. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
Ville Skyttä wrote: I suggest maintainers take this opportunity to review whether all these packages really need to be linked against libpng - I'm positive that the list contains a lot of packages that don't. -Wl,--as-needed in LDFLAGS (in addition to RPM_LD_FLAGS) is one easy way that can be applied in many cases to get rid of unnecessary linkage bloat. Why is this not the default in Fedora? Mandriva has been using that by default for ages, and it shouldn't be any more invasive than the -Wl,--no-add-needed (note: add != as) change done in Fedora 13. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
Richard Shaw hobbes1...@gmail.com writes: This is my first time as a contributor to run into this. Do I simply need to increment by release by 1 (or .1?) and build? If no source-code changes are needed, then yes, it's sufficient to increment the release number (either way that suits you) and rebuild in rawhide. I assume you're thinking of OpenImageIO? [ checks results of test runs... ] You will need a source-code patch for that one, because it uses the symbol Z_BEST_COMPRESSION, which is exported by zlib.h, which is no longer automatically included by png.h. So you'll need to add #include zlib.h to whichever file(s) need that. It might be that there are further changes needed --- the error on that symbol was as far as my test build got. Once you've got it working, you should pester your upstream to include the changes, since libpng 1.5 is certainly something they're going to have to deal with. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On Sat, Nov 5, 2011 at 2:34 PM, Tom Lane t...@redhat.com wrote: Richard Shaw hobbes1...@gmail.com writes: This is my first time as a contributor to run into this. Do I simply need to increment by release by 1 (or .1?) and build? If no source-code changes are needed, then yes, it's sufficient to increment the release number (either way that suits you) and rebuild in rawhide. I assume you're thinking of OpenImageIO? [ checks results of test runs... ] You will need a source-code patch for that one, because it uses the symbol Z_BEST_COMPRESSION, which is exported by zlib.h, which is no longer automatically included by png.h. So you'll need to add #include zlib.h to whichever file(s) need that. It might be that there are further changes needed --- the error on that symbol was as far as my test build got. Yup, I figured that out! I'm still not a C programmer but my hacker skills are improving. I ended up grep'ing through /usr/include for Z_BEST_COMPRESSION and found that zlib.h had what I needed. I checked upstream and the master branch already has the fix but the (updated) 0.10.3 still does not. I'm doing a local mock build to make sure my patch works. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On Sat, 05 Nov 2011 20:12:28 +0200, VS (Ville) wrote: On 11/05/2011 07:02 PM, Tom Lane wrote: The list of packages that need to be rebuilt is attached. I suggest maintainers take this opportunity to review whether all these packages really need to be linked against libpng - I'm positive that the list contains a lot of packages that don't. Well-spotted, but how to fix it? Lots of executables end up linked with libpng12 due to other libs (cairo, gdk-pixbuf2) being linked with it. Neither -lpng12 or -lpng is added explicitly. -Wl,--as-needed in LDFLAGS (in addition to RPM_LD_FLAGS) is one easy way that can be applied in many cases to get rid of unnecessary linkage bloat. Last time that has come up (long ago!) it didn't work for me. Still doesn't. Example package: geeqie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
Michael Schwendt wrote: Lots of executables end up linked with libpng12 due to other libs (cairo, gdk-pixbuf2) being linked with it. Neither -lpng12 or -lpng is added explicitly. Not due to them being LINKED with it, but due to them shipping .pc or .la files (probably .pc, since we normally don't ship .la files in Fedora) which add -lpng12 when you didn't ask for it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On 11/05/2011 11:20 PM, Michael Schwendt wrote: On Sat, 05 Nov 2011 22:02:42 +0100, KK (Kevin) wrote: Lots of executables end up linked with libpng12 due to other libs (cairo, gdk-pixbuf2) being linked with it. Neither -lpng12 or -lpng is added explicitly. Not due to them being LINKED with it, but due to them shipping .pc or .la files (probably .pc, since we normally don't ship .la files in Fedora) which add -lpng12 when you didn't ask for it. No. If that were the case, -lpng12 would appear on the linker command-line. It doesn't. How are you checking whether your executable ended up linked with something? If with ldd, note that it's recursive. AFAIU for example eu-readelf -d /path/to/something | grep NEEDED shows a better picture which is also mirrored in package dependencies. Configuring geeqie with %configure --enable-lirc LDFLAGS=-Wl,--as-needed ...instead of plain %configure --enable-lirc in a F-15 mock test build I just did from the devel branch dropped the number of shared libs listed in the eu-readelf command above for /usr/bin/geeqie from 25 to 15, and libpng* no longer appears in the resulting package's dependencies. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
Michael Schwendt mschwe...@gmail.com writes: On Sun, 06 Nov 2011 00:03:28 +0200, VS (Ville) wrote: How are you checking whether your executable ended up linked with something? Admittedly, I trusted Tom Lane's list of affected packages, looked at ldd -u -r output and then examined the source. My list was just the result of repoquery --whatrequires. I don't claim to have inquired any more closely than that as to what depends on libpng. I did notice that a lot of them don't seem to have any BuildRequires for libpng --- but that doesn't mean it's not getting pulled in indirectly. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
On Sat, 05 Nov 2011 19:07:44 -0400, TL (Tom) wrote: On Sun, 06 Nov 2011 00:03:28 +0200, VS (Ville) wrote: How are you checking whether your executable ended up linked with something? Admittedly, I trusted Tom Lane's list of affected packages, looked at ldd -u -r output and then examined the source. My list was just the result of repoquery --whatrequires. I don't claim to have inquired any more closely than that as to what depends on libpng. I did notice that a lot of them don't seem to have any BuildRequires for libpng --- but that doesn't mean it's not getting pulled in indirectly. The last Rawhide build of geeqie also doesn't depend on libpng*. F-15 does, however, which might be where you've run repoquery. Never mind. ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
Michael Schwendt mschwe...@gmail.com writes: On Sat, 05 Nov 2011 19:07:44 -0400, TL (Tom) wrote: My list was just the result of repoquery --whatrequires. The last Rawhide build of geeqie also doesn't depend on libpng*. F-15 does, however, which might be where you've run repoquery. Hmm ... actually I did it on an F-14 box. My notes say I did repoquery --repoid=fedora-rawhide --whatrequires ... but I've had problems before with repoquery not doing what I thought it would. Can anyone elucidate on the proper incantation for this? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
Once upon a time, Ville Skyttä ville.sky...@iki.fi said: How are you checking whether your executable ended up linked with something? If with ldd, note that it's recursive. AFAIU for example eu-readelf -d /path/to/something | grep NEEDED shows a better picture which is also mirrored in package dependencies. Hmm, I didn't know that. Which does RPM use when generating dependencies? It would appear that it is is using ldd; should that be changed? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libpng bumped to 1.5.x in rawhide
Chris Adams wrote: Hmm, I didn't know that. Which does RPM use when generating dependencies? It would appear that it is is using ldd; should that be changed? No, RPM does not pull in recursive soname dependencies, only direct ones. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
