Re: cbmc: FTBFS[kfreebsd,hurd]: GCC-4.7
2012/5/20 Christoph Egger : > __GLIBC__ should cover all of them alone. Or alternatively consistently > checking for kernels: > > #if defined(__linux__) || defined(__GNU__) || defined(__FreeBSD_kernel__) Please keep in mind __FreeBSD_kernel__ doesn't imply anything about userland. In fact this macro is defined in recent versions of FreeBSD. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXMUdWK9TaqiR6xKRqYa2B1QWUMg-Xq_XTezJb5FZ=f...@mail.gmail.com
Re: Bug#637777: zeromq: fix kFreeBSD build
On Sun, Aug 14, 2011 at 12:40:25PM +0200, Christoph Egger wrote:
> Package: src:zeromq
> Version: 2.1.7-1
> Severity: important
> Tags: patch
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd-porting
>
> Hi!
Hi,
> Your package failed to build on kfreebsd as the uuid code is
> conditionalized on FreeBSD vs Linux while the code is actually GLIBC /
> BSDLibC specific. Attached patch fixes this problem and allows zeromq to
> build on kfreebsd
I have adapted your patch and, along with another one (see attached), zeromq
seems to compile fine on kfreebsd. The problem now is that the tests segfault.
All of them appear to have the same problem with "sigsuspend":
> (gdb) r
> Starting program: /home/ghedo/pkg-zeromq/tests/.libs/test_pair_inproc
>
> Program received signal ?, Unknown signal.
> __pthread_sigsuspend ()
> at
> ../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
> 24../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:
> No such file or directory.
> (gdb) bt
> #0 __pthread_sigsuspend ()
> at
> ../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24
> #1 0x000800c643b8 in __pthread_wait_for_restart_signal (self= out>)
> at pthread.c:1285
> #2 0x000800c6507c in suspend (self=) at restart.h:34
> #3 __pthread_create_2_1 (thread=0x604650, attr=,
> start_routine=, arg=) at pthread.c:882
> #4 0x00080084380d in zmq::thread_t::start (this=,
> tfn_=, arg_=) at thread.cpp:84
> #5 0x00080083006e in zmq::ctx_t::ctx_t (this=0x602cc0, io_threads_=1)
> at ctx.cpp:59
> #6 0x000800847541 in zmq_init (io_threads_=1) at zmq.cpp:280
> #7 0x004018ad in context_t (io_threads_=1, this=0x7fffe970)
> at ../include/zmq.hpp:204
> #8 zmqtestutil::basic_tests (transport_=0x402236 "inproc://tester", t1_=0,
> t2_=0)
> at testutil.hpp:82
> #9 0x00401342 in main (argc=, argv=)
> at test_pair_inproc.cpp:29
(this was run on asdfasdf.d.n using the package at [0])
Any idea on what may be causing this?
Cheers
[0] http://anonscm.debian.org/gitweb/?p=collab-maint/zeromq.git
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
Description: Fix FTBFS on kfreebsd by adjusting uuid include paths
Origin: vendor
Bug-Debian: http://bugs.debian.org/63
Author: Alessandro Ghedini
Reviewed-by: Alessandro Ghedini
Last-Update: 2012-05-21
--- a/src/uuid.cpp
+++ b/src/uuid.cpp
@@ -44,7 +44,8 @@
return (char*) string_buf;
}
-#elif defined ZMQ_HAVE_FREEBSD || defined ZMQ_HAVE_NETBSD || (defined ZMQ_HAVE_HPUX && defined HAVE_LIBDCEKT)
+#elif (defined ZMQ_HAVE_FREEBSD || defined ZMQ_HAVE_NETBSD ||\
+ (defined ZMQ_HAVE_HPUX && defined HAVE_LIBDCEKT)) && !defined __GLIBC__
#include
#ifdef ZMQ_HAVE_HPUX
@@ -79,7 +80,7 @@
}
#elif defined ZMQ_HAVE_LINUX || defined ZMQ_HAVE_SOLARIS ||\
- defined ZMQ_HAVE_OSX || defined ZMQ_HAVE_CYGWIN
+ defined ZMQ_HAVE_OSX || defined ZMQ_HAVE_CYGWIN || defined __GLIBC__
#include
--- a/src/uuid.hpp
+++ b/src/uuid.hpp
@@ -24,12 +24,12 @@
#include "platform.hpp"
#include "stdint.hpp"
-#if defined ZMQ_HAVE_FREEBSD || defined ZMQ_HAVE_NETBSD
+#if (defined ZMQ_HAVE_FREEBSD || defined ZMQ_HAVE_NETBSD) && !defined __GLIBC__
#include
#elif defined ZMQ_HAVE_HPUX && defined HAVE_LIBDCEKT
#include
#elif defined ZMQ_HAVE_LINUX || defined ZMQ_HAVE_SOLARIS ||\
- defined ZMQ_HAVE_OSX || defined ZMQ_HAVE_CYGWIN
+ defined ZMQ_HAVE_OSX || defined ZMQ_HAVE_CYGWIN || defined __GLIBC__
#include
#elif defined ZMQ_HAVE_WINDOWS
#include "windows.hpp"
--- a/configure.in
+++ b/configure.in
@@ -123,6 +123,13 @@
fi
;;
*freebsd*)
+case "${host_os}" in
+*kfreebsd*)
+AC_CHECK_LIB(uuid, uuid_generate, ,
+[AC_MSG_ERROR([cannot link with -luuid, install uuid-dev.])])
+;;
+esac
+
# Define on FreeBSD to enable all library features
CPPFLAGS="-D__BSD_VISIBLE $CPPFLAGS"
AC_DEFINE(ZMQ_HAVE_FREEBSD, 1, [Have FreeBSD OS])
--- a/configure
+++ b/configure
@@ -17116,6 +17217,58 @@
fi
;;
*freebsd*)
+case "${host_os}" in
+*kfreebsd*)
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for uuid_generate in -luuid" >&5
+$as_echo_n "checking for uuid_generate in -luuid... " >&6; }
+if ${ac_cv_lib_uuid_uuid_generate+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ ac_check_lib_save_LIBS=$LIBS
+LIBS="-luuid $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+/* Override any GCC internal prototype to avoid an error.
+ Use char because int might match the return type of a GCC
+ builtin and then its argument prototype would still apply. */
+#ifdef __cplusplus
+extern "C"
+#endif
+char uuid_generate ();
+int
+main ()
+{
+return uuid_generate ();
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+ ac_cv_lib_uuid_uuid
Re: Bug#637777: zeromq: fix kFreeBSD build
Hi, Unfortunately this is a (quite serious) bug #669043 in gdb on GNU/kFreeBSD. It is not the test program causing this: >> (gdb) r >> Starting program: /home/ghedo/pkg-zeromq/tests/.libs/test_pair_inproc >> >> Program received signal ?, Unknown signal. >> __pthread_sigsuspend () >> at >> ../ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/linuxthreads/pt-sigsuspend.S:24 Maybe you could enable core dumps (ulimit -c) when running the test program and use gdb with that instead? Or gdb 7.4.1-1.1 should be accepted into unstable tomorrow, hopefully fixing this. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fba8881.3060...@pyro.eu.org
Re: OpenJDK-7 on kFreeBSD (feedback)
On 05/20/2012 04:51 PM, Roger Leigh wrote: On Sun, May 20, 2012 at 03:41:56PM +0300, Georgi Naplatanov wrote: There's 1.5.2-1 in experimental. It should just rebuild for squeeze. I would not expect the schroot version to be a problem though. schroot is after all just a fancy wrapper around chroot(8). If schroot is causing problems, it's likely to be in the process environment or in the chroot environment (mounted filesystems etc.). While different versions of schroot might have slightly different defaults, none of the changes should result in build failures. You could try running schroot with "-p" to use the environment in your session, rather than a clean one. This would help see if it's a process environment issue. You could try running with chroot(8) directly as root, and eliminate schroot entirely. This wouldn't set up any filesystem mounts or do any other setup. Hi Roger. Thank you for your fast replay and explanation. I will compare file system layout for squeeze's and wheeze's chroots (especially /var and /run directories). I saw some differences and will check whether that is a problem. Best regards Georgi -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fba9001.4020...@oles.biz
Re: Bug#673165: mapserver: FTBFS with multiarch-ready libgd2
tag 673165 patch pending
thanks
Steven Chamberlain (18/05/2012):
> 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: […]
That's correct, all archs are affected now.
> 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...
… or to stop trying to do that entirely.
I've just uploaded a fixed package with the attached source debdiff.
Maintainers, that's a very short notice, but we haven't heard from you
on the bug log, and we badly need fixed packages for gdal. Thanks for
your understanding.
Mraw,
KiBi.
diff -Nru mapserver-6.0.1/debian/changelog mapserver-6.0.1/debian/changelog
--- mapserver-6.0.1/debian/changelog 2012-03-05 16:09:41.0 +0100
+++ mapserver-6.0.1/debian/changelog 2012-05-22 01:31:07.0 +0200
@@ -1,3 +1,12 @@
+mapserver (6.0.1-3.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fix FTBFS with multiarch libgd by just using -lgd instead of trying to
+locate libgd.{a,so}, new patch: multiarch-libgd (Closes: #673165).
+ * Set urgency to “high” for the RC bug fix, needed for the gdal transition.
+
+ -- Cyril Brulebois Tue, 22 May 2012 01:28:15 +0200
+
mapserver (6.0.1-3) unstable; urgency=low
* Let the configure script search in the system directory for jpeg stuff.
diff -Nru mapserver-6.0.1/debian/patches/multiarch-libgd mapserver-6.0.1/debian/patches/multiarch-libgd
--- mapserver-6.0.1/debian/patches/multiarch-libgd 1970-01-01 01:00:00.0 +0100
+++ mapserver-6.0.1/debian/patches/multiarch-libgd 2012-05-22 01:31:07.0 +0200
@@ -0,0 +1,71 @@
+Description: Fix FTBFS with multiarch libgd.
+ The linker knows where to find libgd when one uses -lgd, so stop
+ worrying where libgd.{a,so} are.
+Bug: http://bugs.debian.org/673165
+Author: Cyril Brulebois
+--- a/configure
b/configure
+@@ -7649,17 +7649,7 @@ elif test -n "$with_gd" -a "$with_gd" !=
+ test -f $GD_DIR/include/gd/gd.h && GD_INCLUDE="$GD_DIR/include/gd"
+ test -f $GD_DIR/gd.h && GD_INCLUDE="$GD_DIR"
+
+- 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/.libs/libgd.a && GD_LIBDIR="$GD_DIR/.libs"
+- test -f $GD_DIR/_libs/libgd.a && GD_LIBDIR="$GD_DIR/_libs"
+- test -f $GD_DIR/libgd.a && GD_LIBDIR="$GD_DIR"
+-
+- 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"
+- test -f $GD_DIR/.libs/libgd.so -o -f $GD_DIR/.libs/libgd.sl -o -f $GD_DIR/.libs/libgd.dylib && GD_LIBDIR="$GD_DIR/.libs"
+- test -f $GD_DIR/_libs/libgd.so -o -f $GD_DIR/_libs/libgd.sl -o -f $GD_DIR/_libs/libgd.dylib && GD_LIBDIR="$GD_DIR/_libs"
+- test -f $GD_DIR/libgd.so -o -f $GD_DIR/libgd.sl -o -f $GD_DIR/libgd.dylib && GD_LIBDIR="$GD_DIR"
++ # Let the linker do its job, we really don't need to pass -L$GD_LIBDIR
+
+ echo "$as_me:$LINENO: checking for gdImageCreatePaletteFromTrueColor in -lgd" >&5
+ echo $ECHO_N "checking for gdImageCreatePaletteFromTrueColor in -lgd... $ECHO_C" >&6
+@@ -7805,9 +7795,9 @@ fi
+ GD_NEED_ICONV_LIB="$ICONV_LIB"
+ fi
+
+- if test -n "$GD_INCLUDE" -a -n "$GD_LIBDIR" -a "$IS_GD2" = "true"; then
++ if test -n "$GD_INCLUDE" -a "$IS_GD2" = "true"; then
+ GD_INC=-I$GD_INCLUDE
+- GD_LIB="-L$GD_LIBDIR -lgd"
++ GD_LIB="-lgd"
+ GD_XTRA_LIBS="$GD_XTRA_LIBS $GD_NEED_ICONV_LIB"
+ echo "$as_me:$LINENO: result: using libgd 2.0.28 (or higher) from $GD_LIB $GD_XTRA_LIBS" >&5
+ echo "${ECHO_T}using libgd 2.0.28 (or higher) from $GD_LIB $GD_XTRA_LIBS" >&6
+--- a/configure.in
b/configure.in
+@@ -636,17 +636,7 @@ elif test -n "$with_gd" -a "$with_gd" !=
+ test -f $GD_DIR/include/gd/gd.h && GD_INCLUDE="$GD_DIR/include/gd"
+ test -f $GD_DIR/gd.h && GD_INCLUDE="$GD_DIR"
+
+- 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/.libs/libgd.a && GD_LIBDIR="$GD_DIR/.libs"
+- test -f $GD_DIR/_libs/libgd.a && GD_LIBDIR="$GD_DIR/_libs"
+- test -f $GD_DIR/libgd.a && GD_LIBDIR="$GD_DIR"
+-
+- 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"
+- test -f $GD_DIR/.libs/libgd.so -o -f $GD_DIR/.libs/libgd.sl -o -f $GD_DIR/.libs/libgd.dylib && GD_LIBDIR="$GD_DIR/.libs"
+- test -f $GD_DIR/_libs/libgd.so -o -f $GD_DIR/_libs/libgd.sl -o -f $GD_DIR/_libs/libgd.dylib && GD_LIBDIR="$GD_DIR/_libs"
+- test -f $GD_DIR/libgd.so -o -f $GD_DIR/libgd.sl -o -f $GD_DIR/libgd.dylib && GD_LIBDIR
Bug#673165 closed by Cyril Brulebois (Bug#673165: fixed in mapserver 6.0.1-3.1)
This is an automatic notification regarding your Bug report
which was filed against the src:mapserver package:
#673165: mapserver: FTBFS with multiarch-ready libgd2
It has been closed by Cyril Brulebois .
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Cyril Brulebois
by
replying to this email.
--
673165: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673165
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: mapserver
Source-Version: 6.0.1-3.1
We believe that the bug you reported is fixed in the latest version of
mapserver, which is due to be installed in the Debian FTP archive:
cgi-mapserver_6.0.1-3.1_amd64.deb
to main/m/mapserver/cgi-mapserver_6.0.1-3.1_amd64.deb
libmapscript-perl_6.0.1-3.1_amd64.deb
to main/m/mapserver/libmapscript-perl_6.0.1-3.1_amd64.deb
libmapscript-ruby1.8_6.0.1-3.1_amd64.deb
to main/m/mapserver/libmapscript-ruby1.8_6.0.1-3.1_amd64.deb
libmapscript-ruby1.9.1_6.0.1-3.1_amd64.deb
to main/m/mapserver/libmapscript-ruby1.9.1_6.0.1-3.1_amd64.deb
libmapscript-ruby_6.0.1-3.1_all.deb
to main/m/mapserver/libmapscript-ruby_6.0.1-3.1_all.deb
mapserver-bin_6.0.1-3.1_amd64.deb
to main/m/mapserver/mapserver-bin_6.0.1-3.1_amd64.deb
mapserver-doc_6.0.1-3.1_all.deb
to main/m/mapserver/mapserver-doc_6.0.1-3.1_all.deb
mapserver_6.0.1-3.1.debian.tar.gz
to main/m/mapserver/mapserver_6.0.1-3.1.debian.tar.gz
mapserver_6.0.1-3.1.dsc
to main/m/mapserver/mapserver_6.0.1-3.1.dsc
php5-mapscript_6.0.1-3.1_amd64.deb
to main/m/mapserver/php5-mapscript_6.0.1-3.1_amd64.deb
python-mapscript_6.0.1-3.1_amd64.deb
to main/m/mapserver/python-mapscript_6.0.1-3.1_amd64.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 673...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Cyril Brulebois (supplier of updated mapserver package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Tue, 22 May 2012 01:28:15 +0200
Source: mapserver
Binary: php5-mapscript libmapscript-perl cgi-mapserver python-mapscript
mapserver-bin mapserver-doc libmapscript-ruby libmapscript-ruby1.8
libmapscript-ruby1.9.1
Architecture: source all amd64
Version: 6.0.1-3.1
Distribution: unstable
Urgency: high
Maintainer: Debian GIS Project
Changed-By: Cyril Brulebois
Description:
cgi-mapserver - CGI executable for MapServer
libmapscript-perl - Perl MapServer module
libmapscript-ruby - Ruby MapServer library
libmapscript-ruby1.8 - Ruby MapServer library
libmapscript-ruby1.9.1 - Ruby MapServer library
mapserver-bin - MapServer utilities
mapserver-doc - documentation for MapServer
php5-mapscript - php5-cgi module for MapServer
python-mapscript - Python library for MapServer
Closes: 673165
Changes:
mapserver (6.0.1-3.1) unstable; urgency=high
.
* Non-maintainer upload.
* Fix FTBFS with multiarch libgd by just using -lgd instead of trying to
locate libgd.{a,so}, new patch: multiarch-libgd (Closes: #673165).
* Set urgency to “high” for the RC bug fix, needed for the gdal transition.
Checksums-Sha1:
7a603d1db67ad4b25dd48e6265ebf5b6d1fff8ac 2337 mapserver_6.0.1-3.1.dsc
8bd7ec275f90e9e65f944a130790d9a64e71a655 27957
mapserver_6.0.1-3.1.debian.tar.gz
2579ab7eab255546d6e5413259c9e2e8f2ae4b6c 93998 mapserver-doc_6.0.1-3.1_all.deb
86554bf1f0084d23f387f884f09def08baaa72f1 68580
libmapscript-ruby_6.0.1-3.1_all.deb
1124ba3cfce62d9b13403299c3695dfa52c80bb7 1023350
php5-mapscript_6.0.1-3.1_amd64.deb
af5f9bd268cd95392ffb7a24b53624327d8c4392 1178416
libmapscript-perl_6.0.1-3.1_amd64.deb
81f700cea1bddd3caa7bad54195f4e8d57e21101 820410
cgi-mapserver_6.0.1-3.1_amd64.deb
40c1862e6e6e8610a3718155f9ad543f476228e8 2033170
python-mapscript_6.0.1-3.1_amd64.deb
07d0e017f1f9f20414bb022ad3acad58c58cc120 6707006
mapserver-bin_6.0.1-3.1_amd64.deb
b665f8c2c178570fc8ad635c35caa6a6a959b81b 1082064
libmapscript-ruby1.8_6.0.1-3.1_amd64.deb
318c3f6142787e55b13d8ac4106543ea39f03cd5 1082388
libmapscript-ruby1.9.1_6.0.1-3.1_amd64.deb
Checksums-Sha256:
b99fba94c3150c6756741cf39cc9a49dc2c6121685672ebc9615379f5771329d 2337
mapserver_6.0.1-3.1.dsc
93dea4c4cfec35bce35af6c8289f752fcc89ccf20bc5d9c7ae408b1b5e366af8 27957
mapserver_6.0.1-3.1.debian.tar.gz
02130946c2d7c187533fd174af837992e87695b3f283cb63bbdcfe86be838a18 93998
mapserver-doc_6.0.1-3.1_all.deb
6caec9bd787ede9adb9ed2f5bd45c514961c16417ff644fb5a2ebcdc67a43427 68580
libmapscript-ruby_6.0.1-3.1_all.deb
c6ad25bc1f0b6f9185f51c792364aaa0aa5d7707b0b037aa93707a
