What to do when GLib required is > 2.40

[francois]

What to do when GLib required is > 2.40. I am trying to build ufraw on porteus 4.0? One of its libraries asks for a more recent GLib than the one on Porteus? Or am I wrong

Code: Select all

root@porteus:~# usm -b ufraw


NAME :  ufraw 
CATEG: graphics
DESC : dcraw gtkimageview lensfun
VERS : 0.22

 Would you like to attempt to build this from source? [y/n]
...

...
mv -f .deps/ufraw_lens_ui.Tpo .deps/ufraw_lens_ui.Po
rm -f libufraw.a
ar cru libufraw.a dcraw.o ufraw_ufraw.o ufraw_routines.o ufraw_colorspaces.o ufraw_developer.o ufraw_conf.o ufraw_writer.o ufraw_embedded.o ufraw_message.o ufobject.o ufraw_settings.o ufraw_lensfun.o wb_presets.o dcraw_api.o dcraw_indi.o nikon_curve.o uf_gtk.o ufraw_exiv2.o iccjpeg.o ufraw_preview.o ufraw_saver.o ufraw_delete.o ufraw_chooser.o ufraw_icons.o curveeditor_widget.o ufraw_lens_ui.o 
ranlib libufraw.a
gcc -DHAVE_CONFIG_H -I.  -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -I/usr/include/lensfun -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -I/usr/include/libpng16  -DDCRAW_NOMAIN -DUFRAW_LOCALEDIR=\"/usr/share/locale\"   -O2 -fPIC -fopenmp -MT ufraw-batch.o -MD -MP -MF .deps/ufraw-batch.Tpo -c -o ufraw-batch.o ufraw-batch.c
mv -f .deps/ufraw-batch.Tpo .deps/ufraw-batch.Po
g++  -O2 -fPIC -fopenmp   -o ufraw-batch  ufraw-batch.o libufraw.a  -lexiv2 -lgthread-2.0 -pthread -lglib-2.0 -llcms2 -llensfun -ltiff -lpng16 -lz   -ljpeg -lbz2 -lz -lm  
/usr/lib64/gcc/x86_64-slackware-linux/7.3.0/../../../../lib64/liblensfun.so: undefined reference to `log@GLIBC_2.29'
/usr/lib64/gcc/x86_64-slackware-linux/7.3.0/../../../../lib64/liblensfun.so: undefined reference to `pow@GLIBC_2.29'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:785: ufraw-batch] Error 1
make[2]: Leaving directory '/tmp/SBo/ufraw-0.22'
make[1]: *** [Makefile:1026: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/ufraw-0.22'
make: *** [Makefile:581: all] Error 2

root@porteus:~#

Code: Select all

root@porteus:~# locate GLib
/usr/share/gir-1.0/DBusGLib-1.0.gir
/usr/share/gir-1.0/GLib-2.0.gir
/usr/share/dbus-1/services/org.gtk.GLib.PACRunner.service
/usr/lib64/python2.7/site-packages/gi/overrides/GLib.py
/usr/lib64/python2.7/site-packages/gi/overrides/GLib.pyc
/usr/lib64/python2.7/site-packages/gi/overrides/GLib.pyo
/usr/lib64/girepository-1.0/DBusGLib-1.0.typelib
/usr/lib64/girepository-1.0/GLib-2.0.typelib
/usr/lib64/python3.6/site-packages/gi/overrides/GLib.py
/usr/lib64/python3.6/site-packages/gi/overrides/__pycache__/GLib.cpython-36.opt-1.pyc
/usr/lib64/python3.6/site-packages/gi/overrides/__pycache__/GLib.cpython-36.pyc
root@porteus:~# 

[ncmprhnsbl]

not sure where you're getting glibc "2.40" from ... the newest version is 2.32 and slackware current is at 2.30 and porteus 4.0 has 2.27 ...
just guessing from that output: looks like liblensfun (package: lensfun) has been compiled against glibc 2.29..(which no longer readily available as a package for slackware)
the best approach imo is to compile lensfun(and most likely any other deps) for the glibc you have ie. 2.27 , install them and then compile ufraw.

why does this happen? because even though a repository is labeled "current" doesn't mean it's contents are in sync with slackware current.
and furthermore, porteus 4.0 was built with what was current in 2018, so many packages built current now or for 14.2 will not work (depending on what they depend on )

[beny]

hi francois and ncmprhnsbl in current slackware ufraw do not compile all the other deps no problem

[ncmprhnsbl]

thanks beny, though francois is targeting porteus 4.0..
looking a little closer, seems like ufraw is old and perhaps outdated (last update: 2015) and distros that package it rely on a bunch of patches..
looks like arch has dropped it altogether in favour of nufraw https://sourceforge.net/projects/nufraw/files/
might be worth trying that
this AUR pkgbuild might give some hints on deps and compile options: https://aur.archlinux.org/cgit/aur.git/ ... D?h=nufraw

there is also the other way to go: ie. use 14.2 packages including glibc-2.23 ... i think two glibc versions can coexist, maybe ..just not very efficient..

[Rava]

Also one thing to consider

GLIBC is the GNU main C library. All C programs link against the GLIBC and need GLIBC "functions" to work.

You cannot have a program compiled against a never version of GLIBC than the GLIBC from the running system - unless you also upgrade all programs to the very same GLIBC version, and also upgrade the system's GLIBC. (Probably unless you're creating the program as an AppImage.)
Usually modules for older Porteus e.g. for 3.1x86-64 or 4.0x86-64 also run in 5.0rc[12], but that is a program compiled against an older version of GLIBC - not compiled against a newer version of GLIBC than the one in the running system. (upwards compatibility versus downwards compatibility)

[francois]

Thanks folks. So I conclude that nufraw could be the solution, is this right.

Code: Select all

root@porteus:/# git clone https://git.code.sf.net/p/nufraw/git nufraw-git
Cloning into 'nufraw-git'...
remote: Enumerating objects: 181, done.
remote: Counting objects: 100% (181/181), done.
remote: Compressing objects: 100% (146/146), done.
remote: Total 181 (delta 54), reused 146 (delta 32)
Receiving objects: 100% (181/181), 850.35 KiB | 0 bytes/s, done.
Resolving deltas: 100% (54/54), done.
Checking connectivity... done

root@porteus:/# ufraw
ufraw: error while loading shared libraries: libgtkimageview.so.0: cannot open shared object file: No such file or directory
root@porteus:/# updatedb
root@porteus:/# locate libgtkimageview.so

root@porteus:/# usm -g gtkimageview

 The following items were found.
 Choose an number to confirm. 
 ctrl+c to quit

1) gtkimageview-1.6.4-x86_64-3_slonly.txz
#? 1

Processing:   gtkimageview-1.6.4-x86_64-3_slonly.txz 
Ignored libraries: 

Libraries required:  15
Libraries found in system: 15
Libraries to resolve: 0



 The following packages are required. 
gtkimageview-1.6.4-x86_64-3_slonly.txz [348K] [not installed]

Total size: 348 KB
 Would you like to install the package/s? (custom paths are supported) [y/n]

 Press [r] to remove packages, [q] to quit, or enter to start downloading.
gtkimageview-1.6.4-x86_64-3_slonly.txz already exists

 Commencing package conversion ... 

Verifying package gtkimageview-1.6.4-x86_64-3_slonly.txz.
Installing package gtkimageview-1.6.4-x86_64-3_slonly.txz:
PACKAGE DESCRIPTION:
# gtkimageview (a simple image viewer widget for GTK)
#
# GtkImageView is a simple image viewer widget for GTK. Similar to the
# image viewer panes in gThumb or Eye of Gnome. It makes writing image
# viewing and editing applications easy.
#
# Homepage: https://github.com/GNOME/gtkimageview
#
/sbin/ldconfig: /usr/lib64/libkdeinit5_kcminit.so is not a symbolic link

Executing install script for gtkimageview-1.6.4-x86_64-3_slonly.txz.
Package gtkimageview-1.6.4-x86_64-3_slonly.txz installed.

Creating /tmp/usm/gtkimageview-1.6.4-x86_64-3_slonly.xzm

Quiet mode: off
[b]Updating shared library links:  /sbin/ldconfig
/sbin/ldconfig: /usr/lib64/libkdeinit5_kcminit.so is not a symbolic link[/b]

root@porteus:/# ufraw
ufraw: /usr/lib64/libtiff.so.5: no version information available (required by ufraw)
ufraw: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /usr/lib64/liblensfun.so.1)

root@porteus:/# locate libm.so
/usr/lib64/libm.so
/lib64/libm.so.6

root@porteus:/# ldd --version
ldd (GNU libc) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
root@porteus:/# 

I have the impression that I have the same problem with nufraw.
Thanks for looking at it.