Solved Should I care about "pkg check -d" output if my systems are installed and updated via ports system?

Status
Not open for further replies.
H

Hanky-panky

Guest
Like in the subject.
I ask because in the past I always had consistency between commands pkg_libcheck -o and
pkg check -d.
This latter report strings like this related to few packages:
Code: 
xfce4-desktop has require a missing libraries: libgdk_pixbuf-2.0.so.0
I checked the file system and those files are perfectly in place, so NOT missing at all. pkglib_chk do not report any error related with the same ports the package was built with.
Should I worry about this? Rebuilding the corresponding ports do not help to fix the issue.
Any idea?
 
I have a similar issue
Code: 
mapnik has require a missing libraries: libgdal.so
If I recompile graphics/mapnik configure says
Code: 
libgdal.so found
I think pkg check interprets something wrong. In the moment I try portmaster -f mapnik (to being sure, it has nothing to do with any dependency). But I think you can ignore it, pkg check doesn't work correctly.
 
talsamon said:
I have a similar issue
Code: 
mapnik has require a missing libraries: libgdal.so
If I recompile graphics/mapnik configure says
Code: 
libgdal.so found
I think pkg check interprets something wrong. In the moment I try portmaster -f mapnik (to beeing sure, it has nothing to do with any depency). But I think you can ignore it, pkg check doesn't work correctly.
Click to expand...

Try to reinstall graphics/gdal.
 
Yes you should be worried about missing shared libraries reported by pkg-check(8). It's a symptom that either you're not building your ports properly or there are problems in the ports and they omit run time dependencies in their Makefiles that should be there.

The benchmark for correctly built ports is always what ports-mgmt/poudriere produces, it would be a good idea to test those ports using it and see if the issue can be replicated there.

Also a note about pkg check -d. It uses only the package metadata to enumerate the provided and required shared libraries, it does not use ldd(1) to actually check which libraries are present or missing. This is in contrast with the pkg_libchk(1) script.
 
Ok, and that means ignore the message from pkg check ??
I don't want (and I think also other users) spend the time to test several ports with poudriere.

It's a symptom that either you're not building your ports properly
Click to expand...
No. I have recompiled now 141 ports (see above), what should be wrong with that?
 
What is so hard about doing this to test a port if it builds properly?

# poudriere testport -j jail -o x11-wm/xfce4-desktop

Without poudriere you would be doing more work to figure out the problems because you have none of the automation that poudriere provides.
 
What is so hard about doing this to test a port if it builds properly?
Click to expand...

The time it needs. (It needs longer to recompile than portmaster cause poudriere runs only - on the "big" ports - with one cpu).
 
talsamon said:
The time it needs. (It needs longer as to recompile than portmaster cause poudriere runs only with one cpu).
Click to expand...

You're incorrect. Poudriere takes advantage of multiple CPUs/cores automatically:

Code: 
# parallel build support.
#
# By default poudriere uses hw.ncpu to determine the number of builders.
# You can override this default by changing PARALLEL_JOBS here, or
# by specifying the -J flag to bulk/testport.
#
# Example to define PARALLEL_JOBS to one single job
# PARALLEL_JOBS=1
 
You're incorrect.
Click to expand...
Maybe, it is not in the detail correct (sometimes I have problems to explain exactly what I mean in English). But poudriere needs longer, that is reality.

But I think, the whole discussion has not much sense. If I mainly work with the ports, it is not from interest what pkg check said. pkg_libchk will be better in this case.
 
kpa said:
Yes you should be worried about missing shared libraries reported by pkg-check(8). It's a symptom that either you're not building your ports properly or there are problems in the ports and they omit run time dependencies in their Makefiles that should be there.

The benchmark for correctly built ports is always what ports-mgmt/poudriere produces, it would be a good idea to test those ports using it and see if the issue can be replicated there.

Also a note about pkg check -d. It uses only the package metadata to enumerate the provided and required shared libraries, it does not use ldd(1) to actually check which libraries are present or missing. This is in contrast with the pkg_libchk(1) script.
Click to expand...
So why pkg_libchk(1) doesn't report anything related with the problem and in my case the supposedly failing package (x11-wm/xfce4-desktop) works completely flawlessly and the ldd command show it correctly linked with the supposedly missing library? I saw many times pkg is still quietly broken, I never pointed my finger on the problem simply because they were minor glitch, this time seems a big mistake.
 
Hanky-panky said:
So why pkg_libchk(1) doesn't report anything related with the problem and in my case the supposedly failing package (xfce4-desktop) works completely flawlessy and the ldd command show it correctly linked with the supposedly missing library? I saw many times pkg is still quietly broken, I never pointed my finger on the problem simply becouse they were minor glitch, this time seems a big mistake.
Click to expand...

Check the ports involved first to see if they declare their run time dependencies properly or not, if they do then it is possible that there is a problem in pkg. I however suspect the former being the issue.
 
The reason why I'm sceptical about this being a pkg problem is that compared to pkg the ports(7) system is very hackish, many times unreliable and contains many hidden surprises for port maintainers and ports system developers when things are updated to support new features.
 
Now, I have tested it with poudriere (only for interest). portmaster needs for 141 ports two hours, poudriere slightly more than two hours for 108 ports.
I installed the pkg, result:
Code: 
pkg check -d
Checking all packages: 100%
mapnik has require a missing libraries: libgdal.so
.
 
talsamon said:
Now, I have tested it with poudriere (only for interest). portmaster needs for 141 ports two hours, poudriere slightly more than two hours for 108 ports.
I installed the pkg, result:
Code: 
pkg check -d
Checking all packages: 100%
mapnik has require a missing libraries: libgdal.so
.
Click to expand...

Could you post what these return with the ports installed:

pkg query -e '%n=mapnik' %n-%v:%B

pkg query -e '%n=gdal' %n-%v:%b

Note the upper/lowercase in %B/%b.
 
Code: 
pkg query -e '%n=mapnik' %n-%v:%B
mapnik-2.2.0_15:libboost_python.so.1.55.0
mapnik-2.2.0_15:libboost_program_options.so.1.55.0
mapnik-2.2.0_15:libfreetype.so.6
mapnik-2.2.0_15:libjpeg.so.8
mapnik-2.2.0_15:libicuuc.so.55
mapnik-2.2.0_15:libsqlite3.so.0
mapnik-2.2.0_15:libpq.so.5
mapnik-2.2.0_15:libcairo.so.2
mapnik-2.2.0_15:libxml2.so.2
mapnik-2.2.0_15:libboost_thread.so.1.55.0
mapnik-2.2.0_15:libboost_filesystem.so.1.55.0
mapnik-2.2.0_15:libpng16.so.16
mapnik-2.2.0_15:libpython2.7.so.1
mapnik-2.2.0_15:libproj.so.9
mapnik-2.2.0_15:libboost_system.so.1.55.0
mapnik-2.2.0_15:libtiff.so.5
mapnik-2.2.0_15:libicui18n.so.55
mapnik-2.2.0_15:libgdal.so
mapnik-2.2.0_15:libboost_regex.so.1.55.0
mapnik-2.2.0_15:libcurl.so.4

pkg query -e '%n=gdal' %n-%v:%b
no output

You may be right with: the error has to do with the run dependencies.
 
This looks like a problem in graphics/gdal. The pkg-plist reads at the end:

Code: 
lib/libgdal.so.%%MAJOR_VER%%
lib/libgdal.so.%%PORTVERSION%%

But MAJOR_VER is not defined (run in the port directory):

Code: 
% make -V MAJOR_VER
<empty>

The ports depending on graphics/gdal still work because they can find libgdal.so.2.0.1 but apparently libgdal.so without the number (.2 probably) at the end is not valid for pkg for some reason.

Edit: The pkg-plist with MAJOR_VER undefined declares the file as libgdal.so. so that's invalid for sure.
 
I was wrong, the MAJOR_VER variable has nothing to do with it. I think I'm on the right track though, libgdal.so.2.0.1 does not have an SONAME defined in it's ELF headers and I'm pretty sure that pkg(8) requires that for it to recognize a shared library in a package.
 
kpa said:
I was wrong, the MAJOR_VER variable has nothing to do with it. I think I'm on the right track though, libgdal.so.2.0.1 does not have an SONAME defined in it's ELF headers and I'm pretty sure that pkg(8) requires that for it to recognize a shared library in a package.
Click to expand...
Just for testing purpose I deleted package graphics/gdk-pixbuf2, rebuild it from ports system and now pkg check -d expose ALL the packages linked with libgdk_pixbuf-2.0.so.0 as requiring it. No need to say everything on pkg_libcheck -o is totally fine.
 
Hanky-panky said:
Just for testing purpose I deleted package gdk-pixbuf2, rebuild it from ports system and now pkg check -d expose ALL the packages linked with libgdk_pixbuf-2.0.so.0 as requiring it. No need to say everything on pkg_libcheck -o is totally fine.
Click to expand...

Do this and report here what it outputs:

readelf -d /usr/local/lib/libgdk_pixbuf-2.0.so.0
 
kpa said:
Do this and report here what it outputs:

readelf -d /usr/local/lib/libgdk_pixbuf-2.0.so.0
Click to expand...
Code: 
Dynamic section at offset 0x1c1d0 contains 30 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libgmodule-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgio-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgobject-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libglib-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libintl.so.8]
 0x00000001 (NEEDED)                     Shared library: [libpng16.so.16]
 0x00000001 (NEEDED)                     Shared library: [libm.so.5]
 0x00000001 (NEEDED)                     Shared library: [libthr.so.3]
 0x00000001 (NEEDED)                     Shared library: [libc.so.7]
 0x0000000e (SONAME)                     Library soname: [libgdk_pixbuf-2.0.so.0]
 0x0000000c (INIT)                       0x4798
 0x0000000d (FINI)                       0x19130
 0x00000004 (HASH)                       0xb4
 0x6ffffef5 (GNU_HASH)                   0x9a4
 0x00000005 (STRTAB)                     0x20e4
 0x00000006 (SYMTAB)                     0xdb4
 0x0000000a (STRSZ)                      6821 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x1d34c
 0x00000002 (PLTRELSZ)                   1824 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x4078
 0x00000011 (REL)                        0x3e50
 0x00000012 (RELSZ)                      552 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x3df0
 0x6fffffff (VERNEEDNUM)                 3
 0x6ffffff0 (VERSYM)                     0x3b8a
 0x6ffffffa (RELCOUNT)                   45
 0x00000000 (NULL)                       0x0
 
make -V MAJOR_VER is a "cosmetic" problem:

if you change
Code: 
PLIST_SUB=      MAJOR_VER=${PORTVERSION:R:R} PORTVERSION=${PORTVERSION}
to
Code: 
MAJOR_VER=  ${PORTVERSION:R:R} 
PLIST_SUB=  ${MAJOR_VER}
you can get an output.

But it solves not the "main problem".
 
Hanky-panky said:
Code: 
Dynamic section at offset 0x1c1d0 contains 30 entries:
  Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library: [libgmodule-2.0.so.0]
0x00000001 (NEEDED)                     Shared library: [libgio-2.0.so.0]
0x00000001 (NEEDED)                     Shared library: [libgobject-2.0.so.0]
0x00000001 (NEEDED)                     Shared library: [libglib-2.0.so.0]
0x00000001 (NEEDED)                     Shared library: [libintl.so.8]
0x00000001 (NEEDED)                     Shared library: [libpng16.so.16]
0x00000001 (NEEDED)                     Shared library: [libm.so.5]
0x00000001 (NEEDED)                     Shared library: [libthr.so.3]
0x00000001 (NEEDED)                     Shared library: [libc.so.7]
0x0000000e (SONAME)                     Library soname: [libgdk_pixbuf-2.0.so.0]
0x0000000c (INIT)                       0x4798
0x0000000d (FINI)                       0x19130
0x00000004 (HASH)                       0xb4
0x6ffffef5 (GNU_HASH)                   0x9a4
0x00000005 (STRTAB)                     0x20e4
0x00000006 (SYMTAB)                     0xdb4
0x0000000a (STRSZ)                      6821 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000003 (PLTGOT)                     0x1d34c
0x00000002 (PLTRELSZ)                   1824 (bytes)
0x00000014 (PLTREL)                     REL
0x00000017 (JMPREL)                     0x4078
0x00000011 (REL)                        0x3e50
0x00000012 (RELSZ)                      552 (bytes)
0x00000013 (RELENT)                     8 (bytes)
0x6ffffffe (VERNEED)                    0x3df0
0x6fffffff (VERNEEDNUM)                 3
0x6ffffff0 (VERSYM)                     0x3b8a
0x6ffffffa (RELCOUNT)                   45
0x00000000 (NULL)                       0x0
Click to expand...

Is there still a problem with that library in pkg check -d?
 
talsamon said:
make -V MAJOR_VER is a "cosmetic" problem:

if you change
Code: 
PLIST_SUB=      MAJOR_VER=${PORTVERSION:R:R} PORTVERSION=${PORTVERSION}
to
Code: 
MAJOR_VER=  ${PORTVERSION:R:R}
PLIST_SUB=  ${MAJOR_VER}
you can get an output.

But it solves not the "main problem".
Click to expand...

Yes I noticed that, the MAJOR_VER variable does not have to be set in the Makefile. It gets set during the creation of the temporary pkg-plist and works as expected.
 
Status
Not open for further replies.
Back
Top