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
