LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   libgmp and libpng in latest -current upgrades (https://www.linuxquestions.org/questions/slackware-14/libgmp-and-libpng-in-latest-current-upgrades-792497/)

dive 03-02-2010 12:23 AM

libgmp and libpng in latest -current upgrades
 
libgmp

If you found slackpkg failed for this upgrade because of libgmp not found you will need to grab the gmp package and install manually.

This way ought to work:

Code:

slackpkg update
slackpkg upgrade glibc-solibs
slackpkg upgrade glibc*
slackpkg upgrade gmp
slackpkg install-new
slackpkg upgrade-all

But if it doesn't work - for a manual install:

Grab the package:

32 bit:
ftp://ftp.osuosl.org/pub/slackware/s...0.1-i486-1.txz

x86_64:
ftp://ftp.osuosl.org/pub/slackware/s...1-x86_64-1.txz

Installpkg probably won't run so move the package to / and do the following:

Code:

cd /
tar xf gmp*txz
source /install/doinst.sh
ldconfig
rm -r /install

When that is done and the rest of the packages are upgraded install gmp package properly.

libpng

There is a problem with icons in xfce and other things which is connected with libpng (workaround below).

http://www.linuxquestions.org/questi...13#post3882213

rworkman 03-02-2010 12:44 AM

Be sure you're in / before doing that untar operation.

Re gtk, it's not a problem with gtk - it's a libpng problem.
I won't say any more right now because I don't want to create any bad blood with an upstream project, and it's not clear as to how it will be solved. For now, if you search around online, find libpng-1.4.0.tar.xz, comment out the manual symlink creation in the SlackBuild script for libpng, and build that version yourself, everything should be fine for now.

If anyone has some spare understanding of how shared library versioning is supposed to work, feel free to FedEx it to the libpng devel team.

rworkman 03-02-2010 12:45 AM

Oh, and I'm off to bed, and the rest of the team is sleeping or busy, so don't wait up expecting a fix.

escaflown 03-02-2010 12:47 AM

Thanks dive! The libgmp was driving me nut:)

escaflown 03-02-2010 12:49 AM

Quote:

Originally Posted by rworkman (Post 3881953)
Oh, and I'm off to bed, and the rest of the team is sleeping or busy, so don't wait up expecting a fix.

:) go get some well deserved sleep, rworkman!

dive 03-02-2010 12:58 AM

Deleted.

ponce 03-02-2010 02:10 AM

thanx dive :)

(i edited the message)

botnet 03-02-2010 04:46 AM

i hope i am not the only one still with the libpng problem (no icons or buttons in gtk applications)



using the stock libpng, i get no icons

using the stock libpng and making a symlink from libpng14.so.14 to libpng.so.14, no icons

building libpng-1.4.0 without the symlinking included in the slackbuild, no icons

building libpng-1.4.0 without the symlinking included in the slackbuild and then manually making a symlink from libpng14.so.14 to libpng.so.14, no icons



Does anyone have icons and buttons in gtk applications after these updates?

gegechris99 03-02-2010 04:57 AM

Quote:

Originally Posted by botnet (Post 3882168)
Does anyone have icons and buttons in gtk applications after these updates?

From Alien Bob's blog:

Quote:

Note for self-compiling folk:

Something you may experience when you compiled your own applications: some of them may suddenly refuse to show buttons/bitmaps. This is because the application is linked in an incompatible way with libpng… it means you will have to recompile it. For instance, I will have to update my own VLC package because the control interface is now showing empty grey squares… bummer.
So do you have problem with all gtk applications or only with the ones you compiled yourself? In the latter case, just recompile your applications.

botnet 03-02-2010 05:02 AM

the problem exists in pidgin and firefox, where i get "broken" icons (a small page with a red X) and with self compiled applications like deluge, i do not get an icon at all

i also have no buttons in firefox i.e. i cannot post with firefox because the submit post button is missing (using chrome to post now)

gegechris99 03-02-2010 05:17 AM

Quote:

Originally Posted by botnet (Post 3882189)
the problem exists in pidgin and firefox

If you feel like it, you can try to recompile pidgin using the official SlackBuild script and see if the icon issue is solved.

The firefox Slackware package is not compiled from source (it's rather a repackaging of firefox binaries). So I'm afraid that, if the root cause of the problem is a wrong link with libpng, then we are stuck for now.

sahko 03-02-2010 05:27 AM

Quote:

Originally Posted by gegechris99 (Post 3882203)
The firefox Slackware package is not compiled from source (it's rather a repackaging of firefox binaries). So I'm afraid that, if the root cause of the problem is a wrong link with libpng, then we are stuck for now.

Thats only for 32bit. The x86_64 package is built from source.

dive 03-02-2010 05:30 AM

OK AlienBob suggested downgrading libpng to 1.4.0 and that seems to have fixed the icon problem.

1) For 32 bit grab the patch libpng.libs.diff.gz from here:

ftp://ftp.osuosl.org/pub/slackware/s...urce/l/libpng/

2) Get the source for libpng 1.2 libpng-1.2.43.tar.xz and slack-desc from here:

ftp://ftp.osuosl.org/pub/slackware/s...urce/l/libpng/

3) Grab the 1.4.0 source here:

http://downloads.sourceforge.net/pro...g-1.4.0.tar.xz

4) You also need the slackbuild but it must be edited for 1.4.0 VERSION and a patch line added. I have one here:

http://www.unrealize.co.uk/source/libpng.SlackBuild

5) Run the script as root ./libpng.SlackBuild

6) Upgradepkg to the new one dropped in /tmp

7) Run update-gdk-pixbuf-loaders and is there is no message/error then it should have worked and you will have icons once more.

For x86_64 you can install AlienBob's package from here:

http://slackware.com/~alien/libpng-1.4.0-x86_64-1.txz

Do as in 6, 7 above.

Hopefully that will have xfce working again :)

piratesmack 03-02-2010 06:39 AM

Quote:

Originally Posted by dive (Post 3882213)
6) Run update-gdk-pixbuf-loaders

I'm getting this error when I run update-gdk-pixbuf-loaders:
Code:

g_module_open() failed for /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so: /usr/lib/libpng14.so.14: undefined symbol: inflateReset
Is anybody else?

dive 03-02-2010 06:59 AM

Quote:

Originally Posted by piratesmack (Post 3882304)
I'm getting this error when I run update-gdk-pixbuf-loaders:
Code:

g_module_open() failed for /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so: /usr/lib/libpng14.so.14: undefined symbol: inflateReset
Is anybody else?

That's the linpng error. See workaround above.

disturbed1 03-02-2010 07:33 AM

Gmp upgrades fine if you tell slackpkg to upgrade it before other things.

slackpkg update
slackpkg upgrade glibc-solibs
slackpkg upgrade glibc*
slackpkg upgrade gmp
slackpkg install-new
slackpkg upgrade-all

dive 03-02-2010 07:43 AM

Yes that's a good point. I shall mention that in top post.

sycamorex 03-02-2010 07:44 AM

thanks guys for the info. It solved the problem with icons on my slack64-current

veeall 03-02-2010 09:57 AM

Do i have to be 'init 1' when upgrading glibc-solibs with slackpkg?

AGer 03-02-2010 12:22 PM

Will this be delivered as a normal package upgrade? You know, I can tolerate KDE for a while...

AGer 03-02-2010 12:26 PM

Why nobody is surprised that a tool that manages packages depends on a package? I would expect both slackpkg and things like upgradepkg to be as statically linked as possible.

dive 03-02-2010 12:46 PM

libpng will probably be upgraded hopefully not too far off. The gmp problem is really to do with the order that things are upgraded I think. It doesn't need a new package built but perhaps an extra check in slackpkg to make sure it's upgraded towards the start of the process.

And anyway slackpkg upgrade-all in my opinion is just an added extra convenience. The best way to upgrade would be to keep a mirror locally and use upgradepkg in the correct order I think.

slackpkg and upgradepkg are shell scripts. They can't be statically linked. But they do rely on other tools to work. There's no way to avoid that.

mRgOBLIN 03-02-2010 04:17 PM

Some fresh updates just released that should help with this issue.

GazL 03-02-2010 04:31 PM

Quote:

Originally Posted by dive (Post 3882213)
OK AlienBob suggested downgrading libpng to 1.4.0 and that seems to have fixed the icon problem.

Does this mean that it's a bug in 1.4.1 and not just a matter of recompiling the apps against the new library version then?

I'd have thought that as all those new slackware packages have just been rebuilt and linked against 1.4.1, downgrading to 1.4.0 would make matters worse as we'd no longer be running with the library version they were compiled against.

I'm a little confused by this now.


edit:

Just checked the new libpng.slackbuild and if I'm reading between the lines correctly, it sounds like a lot of the new packages were built against 1.4.0 and then libpng was updated after that. If that's so then I'm a little less confused than I was a few minutes ago. :)

sahko 03-02-2010 04:42 PM

Quote:

Originally Posted by GazL (Post 3883098)
I'm a little confused by this now.

Forget what Eric said. Theres already an updated libpng in -current. Use that one (along with the other updates).

GazL 03-02-2010 05:20 PM

Quote:

Originally Posted by sahko (Post 3883111)
Forget what Eric said. Theres already an updated libpng in -current. Use that one (along with the other updates).

Yep, will do. Thanks Sahko. I spotted mRgOBLIN's post just after I posted that. I'll throw them on tomorrow when they've propagated through the mirrors.

piratesmack 03-02-2010 05:22 PM

Quote:

Originally Posted by dive (Post 3882323)
That's the linpng error. See workaround above.

OK I must have screwed something up last night when I tried the workaround. I tried it again today and all is working, thank you.

I'll try the official fixes when they hit my Slackware-Current mirror.

dive 03-02-2010 06:40 PM

Well issues solved:

a/coreutils-8.4-i486-2.txz: Rebuilt.
Use --without-gmp, at least for now. We don't want utilities in /bin
requiring a library in /usr/lib{,64} that may not be available.
l/libpng-1.4.1-i486-2.txz: Rebuilt.
Now with less rat.

botnet 03-02-2010 11:09 PM

still have some issue which i assume are related to libpng

i recompiled imlib2 and giblib using the latest slackbuilds but i cannot save png files with scrot (i can save jpg) and i cannot view png files with feh (i can view jpg etc)

Code:

feh WARNING: images/spaceinvaders.png - No Imlib2 loader for that file format
feh - No loadable images specified.

Code:

scrot test.png
giblib error: Saving to file test.png failed

will try to figure out if there are some png specific configure options for either of those that need updating

Speek 03-03-2010 03:58 AM

botnet,

Applying 2 patches to Imlib2 fixed the problem with scrot for me. I don't use feh, so I don't know about that. Good luck!

AGer 03-03-2010 06:42 AM

Quote:

Originally Posted by dive (Post 3882859)
slackpkg and upgradepkg are shell scripts.

Oh yes indeed! Just forgot about that. Installpkg is a shell script too, so theoretically things may get complicated.
Quote:

Originally Posted by dive (Post 3882859)
There's no way to avoid that.

I would say "no reasonable way".

As for the idea that more checks should be added to slackpkg, I guess since the effect is rare and dependency tracking is necessary to be sure (have reasonable basis for hope?) that it will never happen again, it is better to do nothing.

If somebody is still willing to do something, I would propose to make a small Slackware rescue ISO image with, among other things, slackpkg.

disturbed1 03-03-2010 06:51 AM

Quote:

As for the idea that more checks should be added to slackpkg, I guess since the effect is rare and dependency tracking is necessary to be sure (have reasonable basis for hope?) that it will never happen again, it is better to do nothing.
Just some simple logic for which upgrades to perform first should suffice. Rather than upgrading all in alphabetical order, perhaps upgrade by package sets. Then again, this is current, and we're supposed to already know how to do this :)

The Slackware install disc is already a rescue disk. You can create a ~21MB ISO with just the isolinux/ and kernels/ directory. Read isolinux/README.TXT

dive 03-03-2010 07:27 AM

Quote:

Originally Posted by AGer (Post 3883759)
.
I would say "no reasonable way".

The latest upgrade for coreutils removes the dependency to libgmp, so that will help enormously in the future.

Quote:

Originally Posted by Changelog
a/coreutils-8.4-i486-2.txz: Rebuilt.
Use --without-gmp, at least for now. We don't want utilities in /bin
requiring a library in /usr/lib{,64} that may not be available.


botnet 03-03-2010 02:08 PM

thank you speek, that worked perfectly

AGer 03-04-2010 08:48 AM

Quote:

Originally Posted by disturbed1 (Post 3883763)
Just some simple logic for which upgrades to perform first should suffice. Rather than upgrading all in alphabetical order, perhaps upgrade by package sets. Then again, this is current, and we're supposed to already know how to do this :)

I agree that will reduce the probability of a massive upgrade failing since package sets are rudimentary dependency tracking. This may be done since it should not be hard and will not add much complexity. My point is that I do not see how to proof that a mass upgrade will never fail, so just reducing a probability that is already low cannot be a high priority.

Quote:

Originally Posted by disturbed1 (Post 3883763)
The Slackware install disc is already a rescue disk. You can create a ~21MB ISO with just the isolinux/ and kernels/ directory. Read isolinux/README.TXT

I thought about it. I guess the install disk is not a rescue disk since it may be outdated due to changes to slackpkg or the kernel. Unofficial current ISO builds almost solve that, but they are too large. And, naturally, when there is a problem it is too late to do isolinux.

I would agree if it is said that Slackware does not need a rescue disk since is easy to manage and any good LiveCD can be used, but I guess it would be nice to have one if there are no better things to do.

disturbed1 03-04-2010 09:38 AM

Quote:

Originally Posted by AGer (Post 3885450)
I agree that will reduce the probability of a massive upgrade failing since package sets are rudimentary dependency tracking. This may be done since it should not be hard and will not add much complexity. My point is that I do not see how to proof that a mass upgrade will never fail, so just reducing a probability that is already low cannot be a high priority.

I thought about it. I guess the install disk is not a rescue disk since it may be outdated due to changes to slackpkg or the kernel. Unofficial current ISO builds almost solve that, but they are too large. And, naturally, when there is a problem it is too late to do isolinux.

I would agree if it is said that Slackware does not need a rescue disk since is easy to manage and any good LiveCD can be used, but I guess it would be nice to have one if there are no better things to do.

What!?

This is Slackware -current which implies a certain ... anyways ;)


but they are too large.
21MB is too large?
Grab isolinux/ kernels/ from your favorite mirror, and place in a directory ~/slackboot
Code:

cd ~/slackboot
mkisofs -o /tmp/slackware-dvd.iso \
  -R -J -A "Slackware Install" \
  -hide-rr-moved \
  -v -d -N \
  -no-emul-boot -boot-load-size 4 -boot-info-table \
  -sort isolinux/iso.sort \
  -b isolinux/isolinux.bin \
  -c isolinux/isolinux.boot \
  -V "SlackDVD" .
cdrecord /tmp/slackware-dvd.iso

There, 21MB Slackware Rescue disc. The same tools that are used to install Slackware, can be use to rescue Slackware. Networking, recovery, hell I've even rescued Windows systems from the Slackware DVD.

If you must have slackpkg, install it while your in the installation environment. If you can't wget it from the installation environment, place the .txz on the CD and use installpkg. Better yet, extract the initrd and remaster it.
Code:

mkdir /tmp/new.initrd
cd /tmp/new.initrd
cat /slackmirror/isolinux/initrd.img | gzip -cd | cpio -i -H newc

Do your stuff, explode a few packages
Code:

find . | cpio -o -H newc | gzip -9c >../new.initrd.img

AGer 03-05-2010 10:01 AM

Quote:

Originally Posted by disturbed1 (Post 3885534)
There, 21MB Slackware Rescue disc. The same tools that are used to install Slackware, can be use to rescue Slackware. Networking, recovery, hell I've even rescued Windows systems from the Slackware DVD.

There must be some misunderstanding. I agree that lots of things can be done with Slackware DVD and it is possible to get the same or enhanced functionality in much smaller space. The installation media is good enough and sufficient under most scenarios. However, it is not ideal as a rescue disk.

It is possible to customize initrd, but this alone does not result in an ideal rescue disc. To my taste, ideal Slackware rescue CD is like Slax. Unfortunately, Slax itself is not in the best shape right now.

As I see it, the problem that initiated this thread, putting aside unnecessary technical details, is: "since once in 3 years an upgrade goes wrong, it must go seriously wrong once in 30 years". This does not look big enough to me to do anything right now, but why not to evaluate the options?

sahko 03-05-2010 12:40 PM

Quote:

Originally Posted by AGer (Post 3885450)
I thought about it. I guess the install disk is not a rescue disk since it may be outdated due to changes to slackpkg or the kernel. Unofficial current ISO builds almost solve that, but they are too large. And, naturally, when there is a problem it is too late to do isolinux.

The simpler way to run current IMO is to have an rsynced Slackware tree in your computer. Doing that will give you the opportunity to create your own updated custom Slackware ISO everytime theres an update, furthermore one humongous like the latest.

PS. Thats also the reason i dont use slackpkg, which might be a great tool, but IMO its more useful for keeping up with stable releases and things that go into patches/
Keeping up with current means you have to examine the packages you install yourself, & not some automated tool like slackpkg is, cause things might break anytime. If you do that, you might know beforehand and avoid a possible disaster.


All times are GMT -5. The time now is 11:47 AM.