| Summary: | sci-libs/gdal-2.4.1 - ld: /usr/lib/libgif.so: error adding symbols: file in wrong format | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dhalsim <massimo.mattia.info> |
| Component: | Current packages | Assignee: | Sci-geo Project <sci-geosciences> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | jarausch, massimo.mattia.info |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 506276 | ||
| Attachments: |
build log (first part)
build log (second part) |
||
|
Description
Dhalsim
2019-10-03 07:50:26 UTC
(In reply to Dhalsim from comment #0) > partial build log: Please attach the entire build log to this bug report. Created attachment 591674 [details]
build log (first part)
It seems that the issue is on link phase there when linking (see also it on the attachment):
[...]
/bin/sh /var/tmp/portage/sci-libs/gdal-2.4.1/work/gdal-2.4.1/libtool --mode=link --silent x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -lcrypto -lpoppler -ljson-c -L/usr//lib -L/usr/lib [...]
-L specify wrong lib dir. This went wrong since I switched to the newest 'no SYMLINK_LIB' 7.1 amd64 profile.
Created attachment 591676 [details]
build log (second part)
anyway the title of the bug should not refer specifically to libgif.so. As reported in the partial build log ld tries to link all wrong 32bit libraries specified trough -l<commonlibname> parameter. (for example json-c, exapt ans so on) I've tryed another AMD64 gentoo system and I have same issue. Same error emerging gdal 2.4.1 on my gentoo machine:
"/usr/lib/libgif.so: error adding symbols: file in wrong format"
It seems like gdal custom libtool script tries to link a 32 bit lib.
I did the following steps to get past this:
# emerge gdal
which will fail at above error then go to temp working dir:
# cd /var/tmp/portage/sci-libs/gdal-2.4.1/work/gdal-2.4.1
then edit file config.status changing the line that starts with
S["LIBS"]="-lcrypto ...
and contains references to wrong "usr//lib" (twice)
change them to "usr/lib64" (you can keep only one instance)
in my case diff look like this:
1161c1161
< S["LIBS"]="-lcrypto -ljson-c -L/usr//lib -lexpat -lopenjp2 -lgif -ljpeg -lgeotiff -ltiff -lpng -lz -L/usr/ -L/usr//lib -lm -lrt -ldl -lpcre"
---
> S["LIBS"]="-lcrypto -ljson-c -lexpat -lopenjp2 -lgif -ljpeg -lgeotiff -ltiff -lpng -lz -L/usr/ -L/usr/lib64 -lm -lrt -ldl -lpcre"
after this resume with ebuild (because emerge will undo changes):
# ebuild /usr/portage/sci-libs/gdal/gdal-2.4.1.ebuild compile
# ebuild /usr/portage/sci-libs/gdal/gdal-2.4.1.ebuild install
# ebuild /usr/portage/sci-libs/gdal/gdal-2.4.1.ebuild qmerge
if you install a different version than 2.4.1 of gdal with same error then change all "2.4.1" from above to you version.
This is probably due to [1], [2] and --with-libz="${EPREFIX}/usr/" --with-libjson-c="${EPREFIX}/usr/" in ebuild.
[1] https://github.com/OSGeo/gdal/blob/aa38907e1937da576cafaf32d013942b437161f5/gdal/configure.ac#L1130
[2] https://github.com/OSGeo/gdal/blob/aa38907e1937da576cafaf32d013942b437161f5/gdal/configure.ac#L4791
*** Bug 701892 has been marked as a duplicate of this bug. *** Is it still a problem with 3.0.4-r1? @Andreas,Hi, confirmed also with sci-libs/gdal-3.0.4-r1. Still using cubus' edit and recompile workaround to merge. Reagrds. (In reply to Andreas Sturmlechner from comment #9) > Is it still a problem with 3.0.4-r1? No, thanks for reminding me, Helmut |
