found 497964 3.3.0-10
thanks
I've just added a slightly modified version of your patch to a new
release of zeroc-ice packages
Unfortunately, it does not yet work, see
http://buildd.debian-ports.org/build.php?arch=&pkg=zeroc-ice
Small change is still needed:
--- debian/rules-php.mk~ 2008-09-08 09:01:55.000000000 +0000
+++ debian/rules-php.mk 2008-09-08 09:01:55.000000000 +0000
@@ -6,7 +6,7 @@
debian/stamp-build-php:: DEB_MAKE_INVOKE := $(DEB_MAKE_ENVVARS) make \
OPTIMIZE=$(OPTIMIZE) UNAME=$(UNAME) \
LP64=yes lp64suffix= \
- UNAME=$(shell uname | tr '/' '_') \
+ UNAME=$(UNAME) \
LDPLATFORMFLAGS=-g \
prefix=/usr
debian/stamp-build-php:: debian/stamp-build-cpp
but before I request changes upstream I need to understand what is going there.
Of course.
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.
This part have been meant only for debian. The GNU/kFreeBSD uses
glibc, currently with linuxthreads add-on. The pthread_condattr_setclock()
is not implemented in linuxthreads add-on. We might (or better should) try
to adopt NPTL add-on for GNU/kFreeBSD later. Better (for us and hppa)
would be to detect availability of pthread_condattr_setclock() at compile
time.
OTOH your changes in Make.common.rules seem to be cheating to me:
...
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.
IMHO, the per-system Make.rules directly equal to uname without sensible
default is broken approach. Especially for as, because "GNU/kFreeBSD" is
not valid filename. So at least it have to be "uname -s | tr / _".
Your current approach seems be fine for us.
Upstream could create i.e. Make.rules.glibc with content of current
Make.rules.Linux and after that Make.rules.Linux, Make.rules.GNU,
Make.rules.GNU_kFreeBSD which just include Make.rules.glibc.
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.
Current upstream glibc fully supports only Linux and partially hurd,
no other system is supported by upstream. I have not been aware of current
solaris support. Please use "(defined(__GLIBC__) && defined(__FreeBSD_kernel__))"
to restrict recognition only for GNU/kFreeBSD.
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.
IMHO yes.
Many thanks for your care about non-linux architectures.
Petr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
