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 p
Re: Porting valgrind to Debian/kFreeBSD
On Tue, Mar 05, 2013 at 06:36:26PM +0100, Carlos Alberto Lopez Perez wrote:
> Hi!
>
> From some time ago there is available a port of Valgrind to FreeBSD [1]
>
> I tried to compile it on Debian/kFreeBSD, and after some patching
> I was able to compile it on kfreebsd-amd64 sid (didn't tested i386).
>
> Here are some quick instructions to replicate what I did
> (valgrind_kfreebsd.patch is attached)
>
> # wget
> https://bitbucket.org/stass/valgrind-freebsd/downloads/valgrind-freebsd-3.8.0.tar.bz2
> # tar xfav valgrind-freebsd-3.8.0.tar.bz2
> # cd valgrind-freebsd-3.8.0
> # wget
> 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
> -qO config.guess
> # wget
> 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'
> -qO config.sub
> # cat /tmp/valgrind_kfreebsd.patch | patch -p1
> # ./autogen.sh
> # ./configure --prefix=/usr --enable-only64bit
> # make
> # make install [2]
>
> However, it don't works as expected when you run it.
>
> It fails with the error:
> cannot set up thread-local storage: cannot set %fs base address for
> thread-local storage
>
> Which I have no real idea about how to fix.
The error message does not come from valgrind, but from the libc.
According to [0], FreeBSD fully supports TLS only on i386 and ia64 which kinda
explains why your amd64 build does not run (that page looks old though). Try
disabling TLS explicitly on the valgrind build by passing --disable-tls to
./configure.
Cheers
[0] https://wiki.freebsd.org/ThreadLocalStorage
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
signature.asc
Description: Digital signature
Re: Porting valgrind to Debian/kFreeBSD
On Thu, Mar 07, 2013 at 09:00:42PM +0100, Carlos Alberto Lopez Perez wrote:
> I'm not sure if this means that we can finally have valgrind packaged
> for Debian/kFreeBSD.
>
>
> The diffstat between "official" valgrind and this freebsd port is pretty
> big.
Is there any chance that the author(s) of such port would bring the patches
upstream? The patch attached to the bug report [0] looks quite outdated (it
targets valgrind 3.5.0 AFAICT).
> Could something like a new "valgrind-bsd" package based on this
> valgrind-freebsd port be allowed on the archives?
I don't think so, but you can try. You'll need to maintain such port yourself
though, since I have no knowledge/experience (or interest FWIW) in (k)FreeBSD
and I'd probably end up doing more harm than good.
Alternatively, I'd be ok if someone volunteers to maintain the patch set as part
of the "plain" valgrind package (that is co-maintaining the package with me) as
long as the modifications don't impact the Linux builds negatively.
Cheers
[0] https://bugs.kde.org/show_bug.cgi?id=208531
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
signature.asc
Description: Digital signature
Re: Bug#702729: valgrind: build on kfreebsd-amd64
On Fri, Mar 15, 2013 at 07:30:11AM -0500, Jeff Epler wrote:
> On Thu, Mar 14, 2013 at 06:30:43PM +0100, Alessandro Ghedini wrote:
> > I'll have a look as soon as I have some free time. I was also thinking that
> > the
> > patch may be applied only in the kfreebsd builds, so it wouldn't interfere
> > with
> > the linux builds.
>
> That sounds great, but I do not yet have the debian expertise to know
> how to express this in debian/rules (or whereever the appropriate
> location is)
That would be done by calling "quilt pop" before building on every platform
except from kfreebsd-* (or something like that), with the freebsd patch being
the last one in the series. But I can take care of this one.
> > Anyway, as I mentioned on the debian-bsd list the real problem here is not
> > really the patch itself, but finding someone willing to maintain it in the
> > future (at least until it gets merged upstream) since I'm not qualified (nor
> > really interested) in the kfreebsd ports. So would you be willing to
> > continue
> > to maintain the patch in the future? If so you are welcome to push your
> > changes
> > to the collab-maint git repository where valgrind is maintained [0] in a
> > separate branch called, say, "kfreebsd" (possibily without the d/changelog
> > changes).
>
> I have some level of committment to doing software development on
> debian-kfreebsd, and I find valgrind to be a useful tool. That being
> the case I have some stake in whether it works or not. I'm not yet a DD
> so I can't yet do things like push branches onto anonscm.debian.org, but
> it's becoming clear that I should go ahead and become one.
>
> I assume that for the moment it's appropriate to attach any updated
> patches to this bug report. If that's inappropriate, please let me
> know.
No worries, you don't need to be a DD to push to collab-maint repositories
(like valgrind's). You just need an acount on alioth.debian.org and request to
join collab-maint [0], then I'll sponsor your request (also see [1]).
Cheers
[0] http://alioth.debian.org/projects/collab-maint/
[1] https://lists.debian.org/debian-devel-announce/2012/01/msg6.html
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
signature.asc
Description: Digital signature
