SBo scripts not building on current (read 1st post, pls)

lord_ · 11-05-2019, 07:31 AM

Cannot build perl-pango due to some test failures:

https://pastebin.com/raw/YSCCXwzU

I really don't know how to address that, I have everything up to date.

ponce · 11-05-2019, 07:37 AM

Quote:

Originally Posted by lord_

Cannot build perl-pango due to some test failures:

https://pastebin.com/raw/YSCCXwzU

I really don't know how to address that, I have everything up to date.

I think the relevant error is this

Code:

xs/Gtk2.c: loadable library and perl binaries are mismatched (got handshake key 0xce00080, needed 0xcd00080)

mainly it means that you built and installed some perl packages (or something from CPAN) when you have installed a previous version of perl and, after that, you upgraded perl to a version that is binary incompatible with the previous you had installed.
the only practical solution I know for that is uninstall any third-party perl thing you have on your system (the ones shipped with current have been already rebuilt and are okay) and rebuild/reinstall it over the newer perl.

lord_ · 11-05-2019, 08:00 AM

I installed some perl modules though the webmin interface (the suggested ones, I don't remember their names) and they're all up to date.

I solved removing the package perl-gtk2-1.24992-x86_64-1_ponce first.
I was trying to rebuild the last one and perl-pango was a dependency.

ponce · 11-05-2019, 08:11 AM

Quote:

Originally Posted by lord_

I installed some perl modules though the webmin interface (the suggested ones, I don't remember their names) and they're all up to date.

I solved removing the package perl-gtk2-1.24992-x86_64-1_ponce first.
I was trying to rebuild the last one and perl-pango was a dependency.

always remember what's written in the first post of the thread

Quote:

Originally Posted by ponce

SBo supports building its own scripts on clean slackware full installation: we would go crazy trying to support any setup out there that we have not tested ourself for everyone of our 5000+ scripts.
this policy applies also on this humble, unofficial, attempt to let SBo things build on current.
following this it should be obvious that issues related to custom installs shouldn't belong in this thread: please open another one to discuss such things, also if you are not sure if the error you got is related but you are aware that your setup is a non-standard one.
describe your problem here only if you are absolutely sure that it has nothing to do with your custom setup.
there's nothing to be added in our repository for the benefit of other slackers if someone is missing dependencies from a slackware full installation or has stuff installed in /usr/local or has installed other third party non-SBo stuff that might be incompatible and so on.
there's no need to say it but if someone else don't agree with this policy and wants to support also non-standard setups is free to do it (but in another topic

).

so, what is this thread for?
risking to be repetitive, report issues here only if you have already tried the scripts from our repository and they won't build on a clean and full installation of Slackware current.

if you keep having issues in building stuff on the same installation (that doesn't respect those prerequisites), please open a new topic.

emmexx · 11-11-2019, 05:01 PM

Is there any successful experience installing qgis and its dependent packages?

I tried but got a couple of gdal compilation errors.
The 1st one was about poppler, the current version 0.68 makes compilation stop for a pdfobject.cpp file line 1058.
I removed that package and installed the 14.2 64 version of poppler (v. 0.45) and the error was gone.

Unfortunately gdal didn't compile yet. It stopped because of a missing library lcms2.
I don't know why it wasn't installed, or better, it was removed when I updated to current.

I installed the Slackware64 current version, restarted sbopkg -i qgis but gdal stopped again with the following error:

Code:

/bin/grep: /usr/lib64/liblcms2.la: No such file or directory
/bin/sed: can't read /usr/lib64/liblcms2.la: No such file or directory
libtool: link: `/usr/lib64/liblcms2.la' is not a valid libtool archive
make[1]: *** [GNUmakefile:55: libgdal.la] Error 1
make[1]: Leaving directory '/tmp/SBo/gdal-2.2.4'

What can I do? Can I create a .la file? Or is there some compile option to disable the use of .la file?

Thank you
maxx

orbea · 11-11-2019, 05:50 PM

Read the changelog entry concerning .la files in current, it should make the solution very clear.

USUARIONUEVO · 11-11-2019, 06:02 PM

Hi , after last updated imagemagick to API 7.x i found transcode need this patch.

https://git.archlinux.org/svntogit/c...ages/transcode

ponce · 11-11-2019, 11:55 PM

Quote:

Originally Posted by USUARIONUEVO

Hi , after last updated imagemagick to API 7.x i found transcode need this patch.

https://git.archlinux.org/svntogit/c...ages/transcode

I already applied it yesterday

thanks for reporting!

emmexx · 11-12-2019, 12:00 AM

Quote:

Originally Posted by orbea

Read the changelog entry concerning .la files in current, it should make the solution very clear.

I'm sorry but I don't understand your suggestion.
The changelog suggests to remove any third party .la file but my problem is that a 3rd party program (gdal) is trying to use a removed .la file.
The solution should be a patch to gdal or to gdal.SlackBuild that tells the "compiler" not to use .la files.

Other question:
As I wrote in order to compile gdal I had to remove poppler current packages and install the previous version. Now my system is "tainted" in the sbo-git sense. What should I do?

ponce · 11-12-2019, 12:08 AM

Quote:

Originally Posted by emmexx

I'm sorry but I don't understand your suggestion.
The changelog suggests to remove any third party .la file but my problem is that a 3rd party program (gdal) is trying to use a removed .la file.
The solution should be a patch to gdal or to gdal.SlackBuild that tells the "compiler" not to use .la files.

Other question:
As I wrote in order to compile gdal I had to remove poppler current packages and install the previous version. Now my system is "tainted" in the sbo-git sense. What should I do?

your system was actually already tainted regarding the prerequisites asked in the first post: the error you are reporting is relative not to gdal asking for a *.la file but another third party package that you have built in the past (before the date of the removal of the *.la files) that is a dependency of gdal and that linked to liblcms2.la.
you should have no problems building gdal on a clean and full installation of slackware current, I tested it just a few days ago, but you have to use the scripts from this repository (where, for example, gdal is patched for the newer poppler).

emmexx · 11-12-2019, 01:14 AM

Quote:

Originally Posted by ponce

your system was actually already tainted regarding the prerequisites asked in the first post: the error you are reporting is relative not to gdal asking for a *.la file but another third party package that you have built in the past (before the date of the removal of the *.la files) that is a dependency of gdal and that linked to liblcms2.la.
you should have no problems building gdal on a clean and full installation of slackware current, I tested it just a few days ago, but you have to use the scripts from this repository (where, for example, gdal is patched for the newer poppler).

I installed slackware current from scratch at the end of september (you answered to a couple of my posts about sbopkg on slacky.eu). I only used sbo-git to install any package.
The only prerequisite I didn't follow is to rsync sbopkg. I kept my system sort of freezed to last september.
Could I be so unlucky that gdal wasn't already compiling at that time?

Anyway, I can rsync sbopkg but if, as you suggest, my system is already tainted, I'd get some other compilation problem.
Do you have any suggestion on how to find the 3rd party package that in your opinion is the cause of the error?

The error I reported follows this command:

Code:

/bin/sh /tmp/SBo/gdal-2.2.4/libtool --mode=link	g++   -lproj -lpoppler -ljson-c -lfreexl -L/usr/lib64 -lgeos_c -lwebp  -lsqlite3 -lexpat -lopenjp2 -lgif -L/usr/lib64 -L/usr/lib64/lib -ljpeg -lpng -llzma -lz -L/usr/lib64 -L/usr/lib64/lib -lpthread -lm -lrt -ldl  -lpcre   -lcurl             -lxml2 -lz -llzma -lm -ldl  -L/usr/lib64/ -lmariadb  -o libgdal.la ./ogr/gml2ogrgeometry.lo ./ogr/ogr2gmlgeometry.lo ./ogr/ogr_api.lo ./ogr/ogr_expat.lo ./ogr/ogr_fromepsg.lo ./ogr/ogr_geocoding.lo ./ogr/ogr_opt.lo ./ogr/ogr_srs_dict.lo ./ogr/ogr_srs_erm.lo ./ogr/ogr_srs_esri.lo ./ogr/ogr_srs_ozi.lo ./ogr/ogr_srs_panorama.lo ./ogr/ogr_srs_pci.lo ./ogr/ogr_srs_proj4.lo ./ogr/ogr_srs_usgs.lo ./ogr/ogr_srs_validate.lo ./ogr/ogr_srs_xml.lo ./ogr/ogr_srsnode.lo ./ogr/ogr_xerces.lo ./ogr/ograpispy.lo ./ogr/ograssemblepolygon.lo ./ogr/ogrcircularstring.lo ./ogr/ogrcompoundcurve.lo ./ogr/ogrct.lo ./ogr/ogrcurve.lo ./ogr/ogrcurvecollection.lo ./ogr/ogrcurvepolygon.lo ./ogr/ogrfeature.lo ./ogr/ogrfeaturedefn.lo ./ogr/ogrfeaturequery.lo ./ogr/ogrfeaturestyle.lo ./ogr/ogrfielddefn.lo ./ogr/ogrgeomediageometry.lo ./ogr/ogrgeometry.lo ./ogr/ogrgeometrycollection.lo ./ogr/ogrgeometryfactory.lo ./ogr/ogrgeomfielddefn.lo ./ogr/ogrlinearring.lo ./ogr/ogrlinestring.lo ./ogr/ogrmulticurve.lo ./ogr/ogrmultilinestring.lo ./ogr/ogrmultipoint.lo ./ogr/ogrmultipolygon.lo ./ogr/ogrmultisurface.lo ./ogr/ogrpgeogeometry.lo ./ogr/ogrpoint.lo ./ogr/ogrpolygon.lo ./ogr/ogrpolyhedralsurface.lo ./ogr/ogrspatialreference.lo ./ogr/ogrsurface.lo ./ogr/ogrtriangle.lo ./ogr/ogrtriangulatedsurface.lo ./ogr/ogrutils.lo ./ogr/osr_cs_wkt.lo ./ogr/osr_cs_wkt_parser.lo ./ogr/swq.lo ./ogr/swq_expr_node.lo ./ogr/swq_op_general.lo ./ogr/swq_op_registrar.lo ./ogr/swq_parser.lo ./ogr/swq_select.lo /tmp/SBo/gdal-2.2.4/alg/contour.lo /tmp/SBo/gdal-2.2.4/alg/delaunay.lo /tmp/SBo/gdal-2.2.4/alg/gdal_crs.lo /tmp/SBo/gdal-2.2.4/alg/gdal_octave.lo /tmp/SBo/gdal-2.2.4/alg/gdal_rpc.lo /tmp/SBo/gdal-2.2.4/alg/gdal_simplesurf.lo /tmp/SBo/gdal-2.2.4/alg/gdal_tps.lo /tmp/SBo/gdal-2.2.4/alg/gdalapplyverticalshiftgrid.lo /tmp/SBo/gdal-2.2.4/alg/gdalchecksum.lo /tmp/SBo/gdal-2.2.4/alg/gdalcutline.lo /tmp/SBo/gdal-2.2.4/alg/gdaldither.lo /tmp/SBo/gdal-2.2.4/alg/gdalgeoloc.lo /tmp/SBo/gdal-2.2.4/alg/gdalgrid.lo /tmp/SBo/gdal-2.2.4/alg/gdalgridavx.lo /tmp/SBo/gdal-2.2.4/alg/gdalgridsse.lo /tmp/SBo/gdal-2.2.4/alg/gdalmatching.lo /tmp/SBo/gdal-2.2.4/alg/gdalmediancut.lo /tmp/SBo/gdal-2.2.4/alg/gdalpansharpen.lo /tmp/SBo/gdal-2.2.4/alg/gdalproximity.lo /tmp/SBo/gdal-2.2.4/alg/gdalrasterize.lo /tmp/SBo/gdal-2.2.4/alg/gdalrasterpolygonenumerator.lo /tmp/SBo/gdal-2.2.4/alg/gdalsievefilter.lo /tmp/SBo/gdal-2.2.4/alg/gdalsimplewarp.lo /tmp/SBo/gdal-2.2.4/alg/gdaltransformer.lo /tmp/SBo/gdal-2.2.4/alg/gdaltransformgeolocs.lo /tmp/SBo/gdal-2.2.4/alg/gdalwarper.lo /tmp/SBo/gdal-2.2.4/alg/gdalwarpkernel.lo /tmp/SBo/gdal-2.2.4/alg/gdalwarpkernel_opencl.lo /tmp/SBo/gdal-2.2.4/alg/gdalwarpoperation.lo /tmp/SBo/gdal-2.2.4/alg/llrasterize.lo /tmp/SBo/gdal-2.2.4/alg/polygonize.lo /tmp/SBo/gdal-2.2.4/alg/rasterfill.lo /tmp/SBo/gdal-2.2.4/alg/thinplatespline.lo /tmp/SBo/gdal-2.2.4/apps/commonutils.lo /tmp/SBo/gdal-2.2.4/apps/gdal_grid_lib.lo /tmp/SBo/gdal-2.2.4/apps/gdal_rasterize_lib.lo /tmp/SBo/gdal-2.2.4/apps/gdal_translate_lib.lo /tmp/SBo/gdal-2.2.4/apps/gdalbuildvrt_lib.lo /tmp/SBo/gdal-2.2.4/apps/gdaldem_lib.lo /tmp/SBo/gdal-2.2.4/apps/gdalinfo_lib.lo /tmp/SBo/gdal-2.2.4/apps/gdalwarp_lib.lo /tmp/SBo/gdal-2.2.4/apps/nearblack_lib.lo /tmp/SBo/gdal-2.2.4/apps/ogr2ogr_lib.lo /tmp/SBo/gdal-2.2.4/frmts/o/BitMask.lo /tmp/SBo/gdal-2.2.4/frmts/o/BitMask2.lo /tmp/SBo/gdal-2.2.4/frmts/o/BitStuffer.lo /tmp/SBo/gdal-2.2.4/frmts/o/BitStuffer2.lo /tmp/SBo/gdal-2.2.4/frmts/o/CntZImage.lo /tmp/SBo/gdal-2.2.4/frmts/o/EnvisatFile.lo /tmp/SBo/gdal-2.2.4/frmts/o/Huffman.lo /tmp/SBo/gdal-2.2.4/frmts/o/IdrisiDataset.lo /tmp/SBo/gdal-2.2.4/frmts/o/IngrTypes.lo /tmp/SBo/gdal-2.2.4/frmts/o/IntergraphBand.lo /tmp/SBo/gdal-2.2.4/frmts/o/IntergraphDataset.lo /tmp/SBo/gdal-2.2.4/frmts/o/JPEG_band.lo
...
[cut]
... 
/tmp/SBo/gdal-2.2.4/port/cpl_xml_validate.lo /tmp/SBo/gdal-2.2.4/port/cplgetsymbol.lo /tmp/SBo/gdal-2.2.4/port/cplkeywordparser.lo /tmp/SBo/gdal-2.2.4/port/cplstring.lo /tmp/SBo/gdal-2.2.4/port/cplstringlist.lo \
    -rpath /usr/lib64 \
    -no-undefined \
    -version-info 23:3:3

ponce · 11-12-2019, 01:58 AM

Quote:

Originally Posted by emmexx

I installed slackware current from scratch at the end of september (you answered to a couple of my posts about sbopkg on slacky.eu). I only used sbo-git to install any package.

if you have stuff still using the *.la files you probably also installed some prebuilt package that still used them, this is my best guess.

Quote:

The only prerequisite I didn't follow is to rsync sbopkg. I kept my system sort of freezed to last september.
Could I be so unlucky that gdal wasn't already compiling at that time?

no, I patched it in october, so I think you have to delete and resync the repository.

Quote:

Anyway, I can rsync sbopkg but if, as you suggest, my system is already tainted, I'd get some other compilation problem.
Do you have any suggestion on how to find the 3rd party package that in your opinion is the cause of the error?

finding the offending package could need a long search: IMHO the best advice, like orbea already suggested, is the one you can find in the ChangeLog

Quote:

IMPORTANT NOTE: If you have any third party or other packages installed on
your system that don't come with Slackware, and those packages have installed
any .la files, it is very likely that they refer to some .la files which we
have just removed, and that trying to compile against these packages will no
longer work. Luckily, the solution is simple: remove them. This command will
remove any stale .la files from the LD_LIBRARY_PATH:
rm /{,usr/}lib{,64}/*.la

emmexx · 11-12-2019, 02:31 AM

Quote:

Originally Posted by ponce

finding the offending package could need a long search: IMHO the best advice, like orbea already suggested, is the one you can find in the ChangeLog

Ok, but the changelog suggestion is from april 2018. I installed current in september 2019. I searched /usr/lib64 and there are 1179 .la files.
Why is that?
They don't appear to come from 3rp party packages but from slackware itself: gimp, sane, gtk and so on...

Code:

bash-5.0# ls /usr/lib64/*.la
/usr/lib64/libavahi-client.la   /usr/lib64/libminizip.la
/usr/lib64/libavahi-common.la   /usr/lib64/libmp3lame.la
/usr/lib64/libavahi-core.la     /usr/lib64/libnfs.la
/usr/lib64/libavahi-glib.la     /usr/lib64/libpathplan.la
/usr/lib64/libavahi-gobject.la  /usr/lib64/libpoppler-cpp.la
/usr/lib64/libavahi-qt4.la      /usr/lib64/libpoppler-glib.la
/usr/lib64/libavahi-ui-gtk3.la  /usr/lib64/libpoppler-qt4.la
/usr/lib64/libavahi-ui.la       /usr/lib64/libpoppler.la
/usr/lib64/libcdt.la            /usr/lib64/libproj.la
/usr/lib64/libcgraph.la         /usr/lib64/libprotobuf-lite.la
/usr/lib64/libdaemon.la         /usr/lib64/libprotobuf.la
/usr/lib64/libdns_sd.la         /usr/lib64/libprotoc.la
/usr/lib64/libdv.la             /usr/lib64/libquicktime.la
/usr/lib64/libdvdcss.la         /usr/lib64/librsync.la
/usr/lib64/libfreexl.la         /usr/lib64/libschroedinger-1.0.la
/usr/lib64/libgeos.la           /usr/lib64/libspatialindex.la
/usr/lib64/libgeos_c.la         /usr/lib64/libspatialindex_c.la
/usr/lib64/libgvc.la            /usr/lib64/libspatialite.la
/usr/lib64/libgvpr.la           /usr/lib64/libwacom.la
/usr/lib64/libhowl.la           /usr/lib64/libxdot.la
/usr/lib64/libjack.la           /usr/lib64/libxkbcommon-x11.la
/usr/lib64/libjackserver.la     /usr/lib64/libxkbcommon.la
/usr/lib64/liblab_gamut.la      /usr/lib64/mod_spatialite.la

and many others in the subdirectories...

My understanding of the changelog was that current removed .la files. I suppose something went wrong on my system when I updated to current. Or are there any other explanations?

p.s. I found out what 3rd party package could have tainted my system: I had to install Brother printer drivers but I can't find a log file.

ponce · 11-12-2019, 02:39 AM

Quote:

Originally Posted by emmexx

Ok, but the changelog suggestion is from april 2018. I installed current in september 2019. I searched /usr/lib64 and there are 1179 .la files.
Why is that?
They don't appear to come from 3rp party packages but from slackware itself: gimp, sane, gtk and so on...

Code:

bash-5.0# ls /usr/lib64/*.la
/usr/lib64/libavahi-client.la   /usr/lib64/libminizip.la
/usr/lib64/libavahi-common.la   /usr/lib64/libmp3lame.la
/usr/lib64/libavahi-core.la     /usr/lib64/libnfs.la
/usr/lib64/libavahi-glib.la     /usr/lib64/libpathplan.la
/usr/lib64/libavahi-gobject.la  /usr/lib64/libpoppler-cpp.la
/usr/lib64/libavahi-qt4.la      /usr/lib64/libpoppler-glib.la
/usr/lib64/libavahi-ui-gtk3.la  /usr/lib64/libpoppler-qt4.la
/usr/lib64/libavahi-ui.la       /usr/lib64/libpoppler.la
/usr/lib64/libcdt.la            /usr/lib64/libproj.la
/usr/lib64/libcgraph.la         /usr/lib64/libprotobuf-lite.la
/usr/lib64/libdaemon.la         /usr/lib64/libprotobuf.la
/usr/lib64/libdns_sd.la         /usr/lib64/libprotoc.la
/usr/lib64/libdv.la             /usr/lib64/libquicktime.la
/usr/lib64/libdvdcss.la         /usr/lib64/librsync.la
/usr/lib64/libfreexl.la         /usr/lib64/libschroedinger-1.0.la
/usr/lib64/libgeos.la           /usr/lib64/libspatialindex.la
/usr/lib64/libgeos_c.la         /usr/lib64/libspatialindex_c.la
/usr/lib64/libgvc.la            /usr/lib64/libspatialite.la
/usr/lib64/libgvpr.la           /usr/lib64/libwacom.la
/usr/lib64/libhowl.la           /usr/lib64/libxdot.la
/usr/lib64/libjack.la           /usr/lib64/libxkbcommon-x11.la
/usr/lib64/libjackserver.la     /usr/lib64/libxkbcommon.la
/usr/lib64/liblab_gamut.la      /usr/lib64/mod_spatialite.la

and many others in the subdirectories...

My understanding of the changelog was that current removed .la files. I suppose something went wrong on my system when I updated to current. Or are there any other explanations?

p.s. I found out what 3rd party package could have tainted my system: I had to install Brother printer drivers but I can't find a log file.

first you said you installed current from scratch, just above you say you updated to current...

don't get me wrong, but as your system is clearly not a clean and full install of slackware current as indicated in the first post of the topic can you please open a new one to discuss this?

emmexx · 11-12-2019, 02:59 AM

Quote:

Originally Posted by ponce

first you said you installed current from scratch, just above you say you updated to current...

don't get me wrong, but as your system is clearly not a clean and full install of slackware current as indicated in the first post of the topic can you please open a new one to discuss this?

I followed this https://docs.slackware.com/slackware:current
It states "cleanly install or upgrade your installation to the latest stable version first".
So 1st I installed 14.2 and after that I "updated" to current as stated in that page.
But now I fear there are other ways to install current... :-(