Problem with updating PERL, after upgrade from 11.2 to 11.4

Hey

Sorry if I post in the wrong forum category.

I updated (freebsd-update) Freebsd from 11.2 to 11.3 and then to 11.4-RELEASE-p4. System (and all services) works OK ;)
I want update very old ports by postmaster.

I have strange error when trying update perl 5.28 to 5.32.
added in /etc/make.conf
Code:
DEFAULT_VERSIONS+= perl5=5.32
Next:
Code:
portmaster -o lang/perl5.32 lang/perl5.28

And I got error:
Code:
Checking for GNU cc in disguise and/or its version number...
Now, how can we feed standard input to your C preprocessor...
Directories to use for library searches?
[/usr/lib /usr/local/lib /usr/lib/clang/10.0.0/lib /usr/lib]
What is the file extension used for shared libraries? [so]
Make shared library basenames unique? [n]
Build Perl for SOCKS? [n]
Try to use long doubles if available? [n]
Checking for optional libraries...
What libraries to use? [-lpthread -lgdbm -lm -lcrypt -lutil]
What optimizer/debugger flag should be used?
[-O2 -pipe -march=skylake -fstack-protector-strong -fno-strict-aliasing ]
Any additional cc flags?
[-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include]
Let me guess what the preprocessor flags are...
Any additional ld flags (NOT including libraries)?
[-pthread -Wl,-E  -fstack-protector-strong -L/usr/local/lib]
Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:

#include <stdio.h>
int main() { printf("Ok\n"); return(0); }

I used the command:

        cc -o try -O2 -pipe -march=skylake -fstack-protector-strong -fno-strict-aliasing -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib try.c -lpthread -lgdbm -lm -lcrypt -lutil
         ./try

and I got the following output:

/usr/lib/libutil.so: undefined reference to `__pw_scan@FBSDprivate_1.0'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
I can't compile the test program.

When I tying compile that simple try.c is same error with libutil.so. Compilation is OK when i dont use flag -lutil in cc command.


Code:
[root@odin /usr/lib]# ls -al libut*
-r--r--r--  1 root  wheel    9534 21 lip  2017 libutempter_p.a
-r--r--r--  1 root  wheel    9030 21 lip  2017 libutempter.a
-r--r--r--  1 root  wheel    9176 21 lip  2017 libutempter.so
-r--r--r--  1 root  wheel  156194 10 lis 23:44 libutil_p.a
-r--r--r--  1 root  wheel  151200 10 lis 23:44 libutil.a
-r--r--r--  1 root  wheel   77144 21 lip  2017 libutil.so

libutil.so (and other *.so also) is very old ;/ 21 lip 2017 = July 2017, "10 lis" is 10 November 2020 (when I upgraded Freebsd).
How can I update that files?

some other *.so files
Code:
-r--r--r--  1 root  wheel  155426 10 lis 23:44 libusb_p.a
-r--r--r--  1 root  wheel  143892 10 lis 23:44 libusb.a
-r--r--r--  1 root  wheel   88040 21 lip  2017 libusb.so
-r--r--r--  1 root  wheel   91880 10 lis 23:44 libusb.so.3
-r--r--r--  1 root  wheel   21662 10 lis 23:44 libusbhid_p.a
-r--r--r--  1 root  wheel   20806 10 lis 23:44 libusbhid.a
-r--r--r--  1 root  wheel   16944 21 lip  2017 libusbhid.so
-r--r--r--  1 root  wheel   16024 10 lis 23:44 libusbhid.so.4
 
Thanks for answer.
I use ports not package so probably pkg upgrade is not a good solutions.

Now I found interesting things.
ls -al /lib/libu*

-r--r--r-- 1 root wheel 18416 10 lis 23:44 /lib/libufs.so.6
-r--r--r-- 1 root wheel 9472 10 lis 23:44 /lib/libulog.so.0
-r--r--r-- 1 root wheel 6056 10 lis 23:44 /lib/libumem.so.2
-r--r--r-- 1 root wheel 78504 10 lis 23:44 /lib/libutil.so.9
-r--r--r-- 1 root wheel 40832 10 lis 23:44 /lib/libuutil.so.2
are new files. but in /usr/lib/ old (from 2017)
Can I copy files from /lib to /usr/lib ?
/lib/libutil.so.9 to /usr/lib/libutil.so ?
 
I use ports not package
Why? Do you have different options? Did you set different defaults? If you're going to build everything with the default settings then you might as well use packages. Building from ports adds nothing if you're going to stick with the defaults.
 
Why? Do you have different options? Did you set different defaults? If you're going to build everything with the default settings then you might as well use packages. Building from ports adds nothing if you're going to stick with the defaults.
Yes, I changed few options in many ports. Plus in lighttpd change source code (on mod index to enabling posibility low permissions [chmod 400/chown user] with index.php).
I also have unsupported old PHP versions compiled in a custom directory.
Additional compiling from ports with enabling CPU type and optimisations give some performance. But this is not a big problem in nowadays - most users are satisfied with packages ;)
 
I made experiment deleted /usr/lib/libutil.so
and now try.c is compiling ok (maybe compilator get library from /lib) . I hope that file is not needed in other ports ;)

Still I wonder why some files in /usr/lib/*.so sare not updated but *.a files yes.
 
I do also compile everything on-site, as I want the freedom to tune options and insert patches.

I didn't have problems with perl, but these days I am quite eager to upgrade, and when a default version changes, I usually upgrade during the next quarterly. Also I do not use portmaster. I regularly build all ports new in a dedicated chroot with only the required dependencies installed, put these in a repo and then install on target with pkg. So the ports are always built in a fresh installation straight from make installworld.

I found some strange things with installworld. make delete-old[-libs] does not always clean up everything. I realized that after make installworld etc. every file (except /var, /etc and /usr/local) should be newly written. So I looked for old ones, and found lots of them, accumulated over the years. But I did change the options in /etc/src.conf on some occasion, and this seems to be one of the reasons.

And recently I found that make installworld does not touch all files it is supposed to install:

Code:
root@admn:/usr/lib # uname -a
FreeBSD ****************** 11.4-RELEASE-p4 FreeBSD 11.4-RELEASE-p4 #0 r366114M#N988: Fri Sep 25 01:22:55 UTC 2020

This is r366114, it cannot be older than Sep 24. It's probably the -p4 update, with the patches from Sep 15.

Code:
root@admn:/usr/lib # ls -lc libutil*
-r--r--r--  1 root  wheel  151912 Jul  8 10:34 libutil.a
lrwxr-xr-x  1 root  wheel      22 Sep 26 13:20 libutil.so -> ../../lib/libutil.so.9
-r--r--r--  1 root  wheel  156970 Jul  8 10:34 libutil_p.a
root@admn:/usr/lib # ls -lc /lib/libutil*
-r--r--r--  1 root  wheel  78512 Sep 26 13:20 /lib/libutil.so.9

The libutil.a (and lots of others) have not been touched during installworld!
So I thought this is some extra-smartness from the install command, and as this was only a small patchset, they may not have changed. And I did hope the stuff would do the right thing, and didn't investigate further.

Now Your experience shows: it seems to not always do the right thing. Maybe we have a bug.

Sadly, I didn't log the actual install, and deleted the obj tree afterwards.

are new files. but in /usr/lib/ old (from 2017)
Can I copy files from /lib to /usr/lib ?
/lib/libutil.so.9 to /usr/lib/libutil.so ?
That might make things worse and the affair more unintellegible.

You could run a make installworld DESTDIR=/someemptydir, and then precisely compare the trees and fix it up as it should be.

P.S. Just seen You use "freebsd-update" for the base system. I have no idea what that does (this thing here is updated from source since Rel. 2.2.1) - but that makes it even more strange. Somebody know the details how freebsd-update would work internally?
 
Code:
root@admn:/usr/lib # ls -lc libutil*
-r--r--r--  1 root  wheel  151912 Jul  8 10:34 libutil.a
lrwxr-xr-x  1 root  wheel      22 Sep 26 13:20 libutil.so -> ../../lib/libutil.so.9
-r--r--r--  1 root  wheel  156970 Jul  8 10:34 libutil_p.a
root@admn:/usr/lib # ls -lc /lib/libutil*
-r--r--r--  1 root  wheel  78512 Sep 26 13:20 /lib/libutil.so.9

The libutil.a (and lots of others) have not been touched during installworld!
Thanks.
A few years ago I also compiled everything from source and do non generic kernels. Now I rely on the binary base and the generic kernel. Only compile ports.
Your post showed me that you have a symbolic link (in /usr/lib) to /lib.libutil.so.9. I wonder why the upgrade didn't do that. And why I had a regular file there.
Maybe that's reason wht the link was not created?
 
Thanks.
A few years ago I also compiled everything from source and my do own kernels. Now I rely on the binary base and the generic kernel. compile ports.
Your post showed me that you have a symbolic link (in /usr/lib) to /lib.libutil.so.9. I wonder why the upgrade didn't do that. And why I had a regular file there.
Maybe that's reason wht the link was not created?

I looked into this a bit further. make installworld calls install -C here, and that is supposed to compare the files and not install if they are identical. So this seems indeed to be the right thing.

This is what should happen:
Code:
[root@admn /usr/lib]# cd /usr/src/lib/libutil
[root@admn /usr/src/lib/libutil]# make -n install
install  -C -o root -g wheel -m 444   libutil.a /usr/lib/
install  -C -o root -g wheel -m 444   libutil_p.a /usr/lib/
install  -s -o root -g wheel -m 444   -S  libutil.so.9 /lib/
install -l rs  /lib/libutil.so.9  /usr/lib/libutil.so

The *.a belong into /usr/lib, and the *.so into /lib, and then there is this symlink.

So in Your case something else must have gone wrong with that binary upgrade.
 
Thank you very much.

I installed pure freebsd 11.4 in digitalocean and downloaded a list of files and links from /usr/lib /usr/lib/i18n and /lib.

I will have to correct it manually (or with some script).
so
a) delete file /usr/lib/xxxx.so (from 2017)
b) link /usr/lib/xxxx.so to file /usr/lib/xxxx.so.X
c) or link to /lib/xxxx.so.X (that kind files is less than b)

I will probably break it down into several stages and check if nothing has broken down after each stage.
There are> 200 files to correct ;)

Of course next will update many ports.
 
After fix symboilic links i run updating perl by postmaster and i got next problem I have python 2.7 and installator want install 3.7
but there are conflict with
pkg-static: py37-setuptools-41.4.0_1 conflicts with py27-setuptools-39.0.1 (installs files into the same place). Problematic file: /usr/local/bin/easy_install
And (re)-installations/updating many ports stops
How can I update python
Now exim (depends to libperl.5.28 i not working) because there are not libperl file (in 5.28 and 5.32 too not exists yet (there files are in work/ ports directory)

portmaster <flags> mail/exim-mysql databases/mariadb103-client devel/cmake archivers/libarchive archivers/liblz4 devel/meson devel/ninja devel/py-setuptools@py37 ...
I remove (pkg delete devel/py-setuptools) py27_* hope i will fix rest but need install many services (Bind, fail2ban and many others) again. I hope will working at Py-37
 
Back
Top