Dear BDFL, and we upgraded ICU in -current because of what shocking new advantages?

ZhaoLin1457 · 04-01-2018, 09:48 AM

Quote:

Originally Posted by Alien Bob

You'll find the previous versions of icu4c and poppler for slackware-current here: http://www.slackware.com/~alien/older_current/
Good luck with it, I have not tried myself.

If I remember right, you replace the poppler with your own version for KDE5?

https://slackware.nl/alien-kde/curre..._64-1alien.txz

Darth Vader · 04-01-2018, 10:03 AM

@ZhaoLin1457

True, Eric replace the poppler package with his own version.

Alien Bob · 04-01-2018, 10:10 AM

The icu4c update is what will hurt you most.

Darth Vader · 04-01-2018, 10:16 AM

Eric, I am just curious...

From your long term experience, how much time you estimate will spend on building your Qt5 5.9.4, a Phenom x4 at 2.3 GHz with 8GB DDR2 800Mhz and classic Western Digital 7200RPM hard drives?

Alien Bob · 04-01-2018, 10:22 AM

Quote:

Originally Posted by Darth Vader

Eric, I am just curious...

From your long term experience, how much time you estimate will spend on building your Qt5 5.9.4, a Phenom x4 at 2.3 GHz with 8GB DDR2 800Mhz and classic Western Digital 7200RPM hard drives?

No idea. I built qt5 and qt5-webkit here, and it took a couple of hours, but that is in a QEMU VM with 8 cores and 8 GB of RAM, running on my Ryzen-powered server.
Still a lot more to compile, though.

ponce · 04-01-2018, 10:43 AM

Quote:

Originally Posted by Darth Vader

PS. Like I shown in another thread:

Code:

bash-4.4# ./server.php
PHP Warning:  PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/lib64/php/extensions/intl (/usr/lib64/php/extensions/intl: cannot open shared object file: No such file or directory), /usr/lib64/php/extensions/intl.so (libicui18n.so.60: cannot open shared object file: No such file or directory)) in Unknown on line 0
Usage: php yourfile.php {start|stop|restart|reload|status|connections} [-d]

That's the glorious standard PHP CLI, aka /usr/bin/php, in a standard -current machine, with the INTL extension loaded.

maybe you are using a custom (or not updated) php package because here

Code:

$ objdump -x /usr/lib64/php/extensions/intl.so | grep NEEDED
  NEEDED               libicui18n.so.61
  NEEDED               libicuuc.so.61
  NEEDED               libicudata.so.61
  NEEDED               libicuio.so.61
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libpthread.so.0
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2

gmgf · 04-01-2018, 10:53 AM

Quote:

Originally Posted by Darth Vader

Eric, I am just curious...

From your long term experience, how much time you estimate will spend on building your Qt5 5.9.4, a Phenom x4 at 2.3 GHz with 8GB DDR2 800Mhz and classic Western Digital 7200RPM hard drives?

Three and a half hours here with an amd AMD FX 6300 six-core, and with the Eric qt5.SlackBuild

dugan · 04-01-2018, 12:03 PM

I saw "icu4c" and I knew I needed to a) check the forum and b) probably wait a a few days. I mean, we had similar issues last time icu4c got upgraded:

https://www.linuxquestions.org/quest...dm-4175619108/
https://www.linuxquestions.org/quest...-a-4175619117/

For those who did update: can't you work around this by symlinking the .so file to what the other packages were built for?

volkerdi · 04-01-2018, 12:12 PM

Quote:

Originally Posted by Darth Vader

Just asking: what advantages gives us icu4c-61.1, compared with icu4c-60.0, excluding that everything is a mess? From your PHP to Eric's Plasma 5, everything is nuts.

As far as I'm aware, nothing actually shipped as part of -current was broken by the update.

Quote:

Be kind to says us WHY you considered is proper to update this package?

I tell you with all respect: you have NO advantages on upgrading to icu4c-61.1. Nothing, nada, zero. Show me at least one CVE and I will be happy, but there is nothing to gain.

I'll tell you this - certain upstream packages such as icu4c, boost, and poppler cause problems for both of us. I've never been able to understand why virtually every release bumps the shared library .soname and requires everything to be recompiled. A little bit of backwards compatibility would be nice.

Regarding icu4c, there have been CVEs in the past, and sometimes it is discovered later on that a newer release fixed them. It's to everyone's benefit that when Slackware 15.0 ships, it contains the most recent possible working versions of libraries. Especially for a library that would be difficult or impossible to replace after the stable release.

Also... I have to chuckle a bit. Are you really suggesting that we shouldn't update something in -current unless there's a CVE?

Happy April Fools and welcome to -current my friend.

glorsplitz · 04-01-2018, 12:38 PM

I have what ponce got from

Code:

objdump -x /usr/lib64/php/extensions/intl.so | grep NEEDED

@dugan A number of people in other slackware threads recommend to NOT do symlinking workarounds, but to each their own.

iamtheshaman · 04-01-2018, 01:26 PM

Hello, I am relatively new to Slackware and to Linux in general, its now my favourite distro and will be sticking with it. I upgraded icu4c today along with the other recompiled packages and it broke alien bobs KDE and Plasma packages that I am using, therefore sddm failed with the missing shared libraries of the old icu4c package when I rebooted.

Having restored my backup, I have followed volkerdi's advice in the thread that dugan posted earlier. Installing the new icu4c package on top of the older one as opposed to upgrading it (I should have thought of that) but thanks volkerdi, and dugan for posting the link that lead me to that.

My question is please are there any drawbacks to having both of the shared libraries in my system? As everything seems to work now fine.
Or is it ok like this as a workaround until a time when the KDE and Plasma packages may be updated in line with icu4c-61.1?

Sorry if this is stupid question. Thanks.

hitest · 04-01-2018, 01:40 PM

Quote:

Originally Posted by Alien Bob

Or go back to what we advise to everyone: use a stable release if you are not able or willing to fix the occasional breakage in -current.

This! ^^^^^

Regnad Kcin · 04-01-2018, 10:33 PM

Lots of us drive around the warnings and use -current because -current is generally the latest and greatest version of Slackware.
I could not imagine going back to 14.2, because I have -current.

Quote:

A number of people in other slackware threads recommend to NOT do symlinking workarounds, but to each their own.

The symlink workaround may be a sort of kludge, but sometimes the only problem is the -name- of the new .so{b} not anything about it's content.

As a sort of roadside repair to get ya on down the road, it is certain better than "Walken".

So what if it needs "more cowbell" now and then?

We can handle it.

teoberi · 04-02-2018, 03:01 AM

Quote:

Lots of us drive around the warnings and use -current because -current is generally the latest and greatest version of Slackware.
I could not imagine going back to 14.2, because I have -current.

I agree, it is my case. And I only use Slackware for servers.

rkfb · 04-02-2018, 03:23 AM

Quote:

Originally Posted by iamtheshaman

[...]

My question is please are there any drawbacks to having both of the shared libraries in my system? As everything seems to work now fine.
Or is it ok like this as a workaround until a time when the KDE and Plasma packages may be updated in line with icu4c-61.1?

Sorry if this is stupid question. Thanks.

I can't answer the question but I have installed jemalloc-3.6.0 from 14.2 alongside the 4.5.0 that comes with current as the qemu available from slackbuilds (2.11.1) seems to have trouble finding 4.5.0 and won't run. Works fine with the 14.2 version however.

I've kept a note that I've installed it and will revisit the situation should any updates appear in the changelog or slackbuild.