Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#23654 - [gdal] 1.8.0-3 WMS layers not working - no curl support

Attached to Project: Community Packages
Opened by Dražen Odobašić (dodobas) - Friday, 08 April 2011, 13:45 GMT
Last edited by Alexander F. Rødseth (xyproto) - Monday, 15 October 2012, 00:42 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jaroslav Lichtblau (Dragonlord)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Gdal has no support for accessing WMS/TMS layers. This functionality depends on curl which is installed.

During execution of makepkg, configure reports that there is on curl support, I've attached config.log. However, if I run configure with the same parameters manually, curl is supported.

Additional info:
* gdal 1.8.0-3
* curl 7.21.4-2

Steps to reproduce:

Try running any examples that can be found on
This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Monday, 15 October 2012, 00:42 GMT
Reason for closing:  No response
Additional comments about closing:  Please reopen if this is still an issue.
Comment by Jelle van der Waa (jelly) - Wednesday, 20 April 2011, 08:09 GMT
Hmm looks interesting, i can't find a enable flag / disable flag for WMS/TMS and i can't even find it in the config.log. How do you think we could fix it?
Comment by Dražen Odobašić (dodobas) - Wednesday, 20 April 2011, 08:11 GMT
there is no flag for WMS/TMS, it depends on curl

no curl no support for WMS/TMS :)

it is possible that complier flags cause problems
Comment by Jelle van der Waa (jelly) - Wednesday, 20 April 2011, 08:28 GMT
hmm we have ./configure --with-curl in our PKGBUILD, i saw an entry that windows need something special, do you know if we need that too?
Comment by Dražen Odobašić (dodobas) - Wednesday, 20 April 2011, 09:18 GMT
yes, but if you check my attached config.log.bad that was generated by running makepkg on line 2907... compile test fails

it doesn't fail when running configure manually without extra compiler options.

makepkg FAIL -> gcc -o conftest -march=x86-64 -mtune=generic -O2 -pipe -fno-strict-aliasing -fPIC -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -lcurl -lodbc -lodbcinst -lexpat -ljasper -lhdf5 -lgif -ljpeg -lpng -lnetcdf -lcfitsio -L/usr/lib -lpq -lz -lpthread -lm -lrt -ldl

normal configure WORKS -> gcc -o conftest -g -O2 conftest.c -lcurl -lodbc -lodbcinst -lexpat -lxerces-c -lpthread -ljasper -lhdf5 -lgif -ljpeg -lpng -lnetcdf -lcfitsio -L/usr/lib -lpq -lz -lpthread -lm -lrt -ldl
Comment by Dražen Odobašić (dodobas) - Wednesday, 04 May 2011, 07:46 GMT
additional info

curl support was failing because of default makepkg LDFLAGS="-Wl,--hash-style=gnu -Wl,--as-needed", specifically "-Wl,--as-needed" part.

By adding specific: export LDFLAGS="-Wl,--hash-style=gnu" to PKGBUILD script gdal compiles with functional curl support.

Should this be reported upstream or fixed in PKGBUILD?

Comment by Jelle van der Waa (jelly) - Sunday, 03 July 2011, 10:38 GMT
Should be fixed , when geos 3.3.0 is moved out of staging then you can test the new gdal in [community-testing]
Comment by Andrzej Giniewicz (Giniu) - Saturday, 24 December 2011, 09:13 GMT
I've seen in 1.8.0-5 that there was a try to fix this:

but this is exactly the part that is offending, and should be disabled. Instead of adding extra LDFLAGS, overwriting what is here already or so, it's best to disable only this single flag with:

export LDFLAGS="$LDFLAGS -Wl,--no-as-needed"

which leaves all other flags in place (like --has-style=gnu) but only disables the --as-needed which causes curl to not link correctly.
Comment by Alexander F. Rødseth (xyproto) - Saturday, 29 September 2012, 00:01 GMT
Is this still an issue?
Comment by Alexander F. Rødseth (xyproto) - Monday, 15 October 2012, 00:42 GMT
No response for over two weeks, closing.