Bug#725383: FTBFS on kfreebsd-*: SYS_gettid is Linux-specific
Source: osgearth Version: 2.4.0+dfsg-5 Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, osgearth fails to build on kfreebsd-* because it tries to directly use a Linux-specific syscall: https://buildd.debian.org/status/package.php?p=osgearthsuite=sid cd /«BUILDDIR»/osgearth-2.4.0+dfsg/build/src/osgEarth /usr/bin/c++ -DOSGEARTH_LIBRARY -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DTIXML_USE_STL -DosgEarth_EXPORTS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -fPIC -isystem /usr/include/qt4 -isystem /usr/include/qt4/QtGui -isystem /usr/include/qt4/QtCore -I/«BUILDDIR»/osgearth-2.4.0+dfsg/src -I/usr/include/gdal -I/usr/include/curl-o CMakeFiles/osgEarth.dir/ThreadingUtils.cpp.o -c /«BUILDDIR»/osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp /«BUILDDIR»/osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp: In function 'unsigned int osgEarth::Threading::getCurrentThreadId()': /«BUILDDIR»/osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp:42:30: error: 'SYS_gettid' was not declared in this scope return (unsigned)::syscall(SYS_gettid); ^ osgearth also knows how to use Windows and Mac OS X--specific syscalls to get a thread ID. This is not portable and there is nothing directly equivalent on FreeBSD, see: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-June/031992.html A workaround may be to use pthread_self(), except that the exported getCurrentThreadId function has to return 'unsigned int'. On kfreebsd-amd64 a 64-bit pointer to a pthread_t is not absolutely guaranteed to be unique if truncated to 32 bits, but it is extremely likely, and certainly better than nothing... Please refer to attached patch which fixes package build at least. Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Index: osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp === --- osgearth-2.4.0+dfsg.orig/src/osgEarth/ThreadingUtils.cpp 2013-04-11 19:07:39.0 +0100 +++ osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp 2013-10-04 22:04:38.898332000 +0100 @@ -20,9 +20,11 @@ #ifdef _WIN32 extern C unsigned long __stdcall GetCurrentThreadId(); -#else +#elif defined(__APPLE__) || defined(__LINUX__) # include unistd.h # include sys/syscall.h +#else +# include pthread.h #endif using namespace osgEarth::Threading; @@ -38,7 +40,10 @@ return (unsigned)::GetCurrentThreadId(); #elif __APPLE__ return ::syscall(SYS_thread_selfid); -#else +#elif __LINUX__ return (unsigned)::syscall(SYS_gettid); +#else + /* :XXX: this truncates to 32 bits, but better than nothing */ + return (unsigned)pthread_self(); #endif } ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#661018: FTBS due to new freexl
Control: fixed -1 3.1.0b-1 I'm marking that version as fixed because 3.0.1-1 never made it into the archive. Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#675972: gdal: FTBFS: fatal error: ruby.h: No such file or directory
Hi, Does gdal need an explicit Build-Depends: ruby1.8 instead of ruby; would that cause the buildscripts to pick the right include paths? /bin/bash /build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/libtool --mode=compile --tag=CXX g++ -g -O2 -Wall -fPIC -DPIC -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/port -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/gcore -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/alg -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/ogr -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/ogr/ogrsf_frmts -I/usr/include/ruby-1.9.1 -I/usr/include/ruby-1.9.1/i486-kfreebsd-gnu -c gdal_wrap.cpp libtool: compile: g++ -g -O2 -Wall -fPIC -DPIC -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/port -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/gcore -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/alg -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/ogr -I/build/buildd-gdal_1.9.0-2+b1-kfreebsd-i386-sJevbb/gdal-1.9.0/ogr/ogrsf_frmts -I/usr/include/ruby-1.9.1 -I/usr/include/ruby-1.9.1/i486-kfreebsd-gnu -c gdal_wrap.cpp -fPIC -DPIC -o .libs/gdal_wrap.o gdal_wrap.cpp:856:18: fatal error: ruby.h: No such file or directory Build-Depends were: ruby ruby1.8-dev The buildd actually resolved these to: libruby1.8_1.8.7.358-4 libruby1.9.1_1.9.3.194-1 ruby_4.9 ruby1.8-dev_1.8.7.358-4 ruby1.9.1_1.9.3.194-1 Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#675972: gdal: FTBFS: fatal error: ruby.h: No such file or directory
tags 675972 + patch thanks Hi, On 04/06/12 21:14, Vincent Fourmond wrote: I've checked that it works changing from ruby to ruby1.8. You probably should try to use ruby1.9.1-dev at a later date. I'm not the maintainer, I was just asking. Thanks a lot for the help! Not tested this myself yet; I expect it to fix this on the buildds, but maybe it could still FTBFS on a system with ruby1.8 and ruby1.9.1 installed together. Then it might need an executable name or shebang line changing somewhere? --- a/debian/control +++ b/debian/control @@ -8,7 +8,7 @@ Build-Depends: debhelper (= 8), zlib1g-dev, libnetcdf-dev (= 1:4.0.0), libhdf4-alt-dev, libhdf5-serial-dev (= 1.6.6), libpq-dev, libxerces-c2-dev, unixodbc-dev (= 2.2.11), python-numpy, doxygen, d-shlibs, libgeos-dev, libmysqlclient-dev, python-all-dev (= 2.6.6-3~), libcurl4-gnutls-dev, libsqlite3-dev, libogdi3.2-dev, - ruby, ruby1.8-dev, chrpath, swig, patch, libexpat1-dev, libproj-dev, + ruby1.8, ruby1.8-dev, chrpath, swig, patch, libexpat1-dev, libproj-dev, libdap-dev, libxml2-dev, libspatialite-dev (= 2.4.0~rc2-4), libepsilon-dev (= 0.9.1), libpoppler-dev, liblzma-dev, libopenjpeg-dev, libarmadillo-dev, libfreexl-dev (= 1.0.0), libkml-dev, liburiparser-dev Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#675972: gdal: FTBFS: fatal error: ruby.h: No such file or directory
On 04/06/12 21:42, Julien Cristau wrote: I'd rather suggest removing gdal's ruby packages. They have no reverse deps in the archive anyway. So if I understand this right, gdal only produces bindings for ruby1.8, which Ruby maintainers want to remove for Wheezy+1 anyway, and no packages in Wheezy are even using them. Therefore I agree. Changing the Build-Depends: ruby - ruby1.8 would fix the current FTBFS on buildds, but the existence of ruby1.9.1 would probably cause FTBFS on other systems. I've noticed this in the upstream changelog though: Ruby bindings: * Build SWIG Ruby Bindings against modern Ruby versions (1.8.7 and 1.9.2) (#3999) Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#673567: qgis: FTBFS with GCC-4.7: 'close' was not declared in this scope
Package: src:qgis Version: 1.7.4+1.7.5~20120320-1 Severity: serious Tags: sid wheezy User: debian-...@lists.debian.org Usertags: ftbfs-gcc-4.7 X-Debbugs-Cc: debian-...@lists.debian.org Justification: fails to build from source (but built successfully in the past) Hi, qgis fails to build on arches that now have gcc-4.7 as default (the successful build on amd64 recently was still using gcc-4.6 at the time): [ 14%] Building CXX object src/core/CMakeFiles/qgis_core.dir/spatialindex/tools/TemporaryFile.cc.o /build/buildd-qgis_1.7.4+1.7.5~20120320-1+b1-i386-O84wRU/qgis-1.7.4+1.7.5~20120320/src/core/spatialindex/tools/TemporaryFile.cc: In constructor 'Tools::TemporaryFile::TemporaryFile()': /build/buildd-qgis_1.7.4+1.7.5~20120320-1+b1-i386-O84wRU/qgis-1.7.4+1.7.5~20120320/src/core/spatialindex/tools/TemporaryFile.cc:52:13: error: 'close' was not declared in this scope /build/buildd-qgis_1.7.4+1.7.5~20120320-1+b1-i386-O84wRU/qgis-1.7.4+1.7.5~20120320/src/core/spatialindex/tools/TemporaryFile.cc: In member function 'void Tools::TemporaryFile::storeNextObject(long unsigned int, const byte*)': /build/buildd-qgis_1.7.4+1.7.5~20120320-1+b1-i386-O84wRU/qgis-1.7.4+1.7.5~20120320/src/core/spatialindex/tools/TemporaryFile.cc:92:15: error: 'close' was not declared in this scope make[3]: *** [src/core/CMakeFiles/qgis_core.dir/spatialindex/tools/TemporaryFile.cc.o] Error 1 make[3]: Leaving directory `/build/buildd-qgis_1.7.4+1.7.5~20120320-1+b1-i386-O84wRU/qgis-1.7.4+1.7.5~20120320/debian/build' make[2]: *** [src/core/CMakeFiles/qgis_core.dir/all] Error 2 Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#673567: qgis: FTBFS with GCC-4.7: 'close' was not declared in this scope
tags 673567 + patch thanks Hi, Attached is a patch which will hopefully fix this on all the affected architectures. Only tested this myself on kfreebsd-i386 though. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org Description: fix to build with GCC 4.7 Must include unistd.h where needed, because GCC 4.7 has stopped including it throughout much of the standard library. . See http://gcc.gnu.org/gcc-4.7/porting_to.html Author: Steven Chamberlain ste...@pyro.eu.org Bug-Debian: http://bugs.debian.org/673567 --- qgis-1.7.4+1.7.5~20120320.orig/src/core/spatialindex/tools/TemporaryFile.cc 2012-05-19 21:42:30.010157000 +0100 +++ qgis-1.7.4+1.7.5~20120320/src/core/spatialindex/tools/TemporaryFile.cc 2012-05-19 21:42:34.797198134 +0100 @@ -20,6 +20,7 @@ //mha...@gmail.com #include stdio.h +#include unistd.h #include Tools.h --- qgis-1.7.4+1.7.5~20120320.orig/src/core/spatialindex/storagemanager/DiskStorageManager.cc 2012-03-17 13:48:08.0 + +++ qgis-1.7.4+1.7.5~20120320/src/core/spatialindex/storagemanager/DiskStorageManager.cc 2012-05-19 21:43:14.837512956 +0100 @@ -25,6 +25,7 @@ #include sys/types.h #include sys/stat.h #include stdio.h +#include unistd.h #include cstring #ifdef WIN32 ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#673165: mapserver: FTBFS with multiarch-ready libgd2
retitle 673165 mapserver: FTBFS with multiarch-ready libgd2 block 645105 by 673165 thanks Hi, This FTBFS (actually on all arches now?) because libgd2 since 2.0.36~rc1~dfsg-6.1 uses a multiarch path, where it is not seen by these checks in configure.in: for GD_DIR in /usr /usr/local do test -f $GD_DIR/include/gd.h GD_INCLUDE=$GD_DIR/include test -f $GD_DIR/lib/libgd.a GD_LIBDIR=$GD_DIR/lib test -f $GD_DIR/lib64/libgd.a GD_LIBDIR=$GD_DIR/lib64 test -f $GD_DIR/lib/libgd.so -o -f $GD_DIR/lib/libgd.sl -o -f $GD_DIR/lib/libgd.dylib GD_LIBDIR=$GD_DIR/lib test -f $GD_DIR/lib64/libgd.so -o -f $GD_DIR/lib/libgd.sl GD_LIBDIR=$GD_DIR/lib64 The path can't be specified from debian/rules via --with-gd because the includes and libraries must all be there. So the configure.in must be modified in some way to look for the static+shared libs in the appropriate (multiarch) path... Regards, -- Steven Chamberlain ste...@pyro.eu.org ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
