Hi Petr, Thank you for the patch and the bug report.
I've just added a slightly modified version of your patch to a new release of zeroc-ice packages but before I request changes upstream I need to understand what is going there. ZeroC Ice source contains several #ifdef __FreeBSD__ what makes me think that FreeBSD (though unsupported) is being used by some staff at ZeroC. But they don't remove monotonic clocks calls on FreeBSD. Therefore I would like to verify whether this stanza should be using __FreeBSD_kernel__ or another more appropriate define: diff -u zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch --- zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch +++ zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch @@ -6,7 +6,7 @@ } -#if !defined(__hpux) && !defined(__APPLE__) -+#if !defined(__hppa) && !defined(__APPLE__) ++#if !defined(__hppa) && !defined(__APPLE__) && !defined(__FreeBSD_kernel__) rc = pthread_condattr_setclock(&attr, CLOCK_MONOTONIC); if(rc != 0) { @@ -18,7 +18,7 @@ return Time(static_cast<Int64>(tb.time) * ICE_INT64(1000000) + tb.millitm * 1000); } -#elif defined(__hpux) || defined(__APPLE__) -+#elif defined(__hppa) || defined(__APPLE__) ++#elif defined(__hppa) || defined(__APPLE__) || defined(__FreeBSD_kernel__) // // HP/MacOS does not support CLOCK_MONOTONIC // OTOH your changes in Make.common.rules seem to be cheating to me: +--- zeroc-ice-3.3.0.orig/config/Make.common.rules ++++ zeroc-ice-3.3.0/config/Make.common.rules +@@ -28,6 +28,15 @@ + UNAME := $(shell uname) + MACHINE_TYPE := $(shell uname -m) + ++ifeq ($(UNAME),GNU/kFreeBSD) ++ UNAME := Linux ++endif ++ ++ifeq ($(UNAME),GNU) ++ UNAME := Linux ++endif ++ ++ I made a variant of this in debian/rules because it breaks the way ZeroC handles different systems. ZeroC includes a per-system Make.rules and therefore if there are two systems similar they should be handled with a common include. For me, the most intringuing stanza is the following: +--- zeroc-ice-3.3.0.orig/cpp/src/IceSSL/Instance.cpp ++++ zeroc-ice-3.3.0/cpp/src/IceSSL/Instance.cpp +@@ -69,7 +69,7 @@ + // On some platforms, pthread_t is a pointer to a per-thread structure. + // + return reinterpret_cast<unsigned long>(pthread_self()); +-#elif (defined(__linux) || defined(__sun) || defined(__hpux)) || defined(_AIX) ++#elif (defined(__linux) || defined(__sun) || defined(__hpux)) || defined(_AIX) || defined(__GLIBC__) + // + // On Linux, Solaris, HP-UX and AIX, pthread_t is an integer. + // You are essentially claiming that all GNU libc on any system are using a pthread_t of type long integer. Are you sure of this? A quick grep into GNU libc source reveals that on Solaris it is defined as a thread_t. Nowadays a thread_t is certainly a long int but it is an indication of GNU libc using the native platform representation for threads. I did not apply the following stanza to the debian package but I will report it upstream. Debian packages do not need to generate a binary distribution other than the one generated by dpkg-buildpackage. Would it be safe to say sys.platform.startswith("gnu")? That would take into account GNU/Hurd too. +--- zeroc-ice-3.3.0.orig/py/makebindist.py ++++ zeroc-ice-3.3.0/py/makebindist.py +@@ -87,7 +87,7 @@ + platform = "" + if sys.platform.startswith("win") or sys.platform.startswith("cygwin"): + platform = "win32" +-elif sys.platform.startswith("linux"): ++elif sys.platform.startswith("linux") or sys.platform.startswith("gnukfreebsd"): + platform = "linux" + elif sys.platform.startswith("sunos"): + platform = "solaris" -- Francisco Moya Fernandez Computer Architecture and Networks Group Assistant Professor [EMAIL PROTECTED] School of Computer Science Fax:(+34 926) 29 53 54 University of Castilla-La Mancha Tel:(+34 926) 29 54 83 http://arco.esi.uclm.es/ -----Original Message----- From: Petr Salinger [mailto:[EMAIL PROTECTED] Sent: Fri 05/09/2008 20:48 To: [EMAIL PROTECTED] Subject: Bug#497964: zeroc-ice: FTBFS on GNU/kFreeBSD Package: zeroc-ice Severity: important Version: 3.3.0-9 Tags: patch User: [EMAIL PROTECTED] Usertags: kfreebsd Hi, the current version fails to build on GNU/kFreeBSD. It needs following changes: * alter of debian/rules-*.mk * extend debian/patches/20-hppa-linux-threads.patch, as the same approach is needed for GNU/kFreeBSD * new debian/patches/20-kfreebsd.patch, GNU/kFreeBSD specific patch Please find attached patch with all needed changes. The override in clean target (UNAME=Linux) is because during "make clean" is not applied 20-kfreebsd.patch which also alters config/Make.common.rules. It would be nice if you can ask upstream to include changes in 20-kfreebsd.patch. Thanks in advance Petr