Emil,
Thanks very much for your patches.
We have finally built libevent successfully on Solaris 10 using Sun
Studio 11 compiler (downloadable for free) and here are the changes
that had to be made :
1) Edit http.c and event_tagging.c to change '__inline' to 'inline'
as mentioned previously
2) Edit event.h to add the following :
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
3) I did not make any changes to configure.in (couldn't get your
suggested changes to work).
Instead, call configure as follows :
./configure CFLAGS= "-fast -xipo -xtarget=generic" LDFLAGS="-
lnsl -lresolv"
1) and 2) above needs to be fixed in the generic source tree. It
would also be great if test/regress.gen.* were supplied, so that one
doesn't require python to be installed.
Shanti
On Jan 2, 2007, at 6:25 PM, Emil Mikulic wrote:
[sorry for the re-post, the first one went out without a Subject:
header
because my fingers got ahead of me...]
Hi there,
I'm building libevent (SVN HEAD) with Sun C 5.8:
$ cc -V
cc: Sun C 5.8 Patch 121015-03 2006/10/18
usage: cc [ options] files. Use 'cc -flags' for details
$ uname -srvmp
SunOS 5.10 Generic_118822-30 sun4u sparc
I've run into a handful of minor portability issues:
______________________________________________________________________
__
0) Minor glitch in autogen.sh:
--- autogen.sh (revision 305)
+++ autogen.sh (working copy)
@@ -1,6 +1,6 @@
#!/bin/sh
LIBTOOLIZE=libtoolize
-if [ "$(uname)" == "Darwin" ] ; then
+if [ "$(uname)" = "Darwin" ] ; then
LIBTOOLIZE=glibtoolize
fi
aclocal && \
______________________________________________________________________
__
1) As Shanti already pointed out in
http://monkeymail.org/archives/libevent-users/2006-December/
000439.html,
two files use __inline. I believe this is non-standard (a GCC-ism)
and
chokes the Sun compiler. Other files already use the more standard
"inline":
[EMAIL PROTECTED]:~/levent/trunk/libevent> grep inline *
buffer.c:static inline void
evdns.c:static inline int
event_tagging.c:static int __inline
http.c:static __inline void
rtsig.c:static inline int
rtsig.c:static inline int
rtsig.c:static inline int
rtsig.c:static inline int
Could you please commit something like the following?
Index: http.c
===================================================================
--- http.c (revision 305)
+++ http.c (working copy)
@@ -1512,7 +1512,7 @@
/* Requires that headers and response code are already set up */
-static __inline void
+static inline void
evhttp_send(struct evhttp_request *req, struct evbuffer *databuf)
{
struct evhttp_connection *evcon = req->evcon;
Index: event_tagging.c
===================================================================
--- event_tagging.c (revision 305)
+++ event_tagging.c (working copy)
@@ -149,7 +149,7 @@
EVBUFFER_LENGTH(_buf));
}
-static int __inline
+static int inline
decode_int_internal(u_int32_t *pnumber, struct evbuffer *evbuf,
int dodrain)
{
u_int32_t number = 0;
______________________________________________________________________
__
2) __func__ is not detected correctly by configure:
$ ./configure
[...]
checking whether our compiler supports __func__... no
checking whether our compiler supports __FUNCTION__... no
[...]
from config.log:
| int
| main ()
| {
| void foo() { const char *cp = __func__; }
| ;
| return 0;
| }
[...]
"conftest.c", line 63: syntax error before or at: {
"conftest.c", line 64: warning: syntax error: empty declaration
"conftest.c", line 65: syntax error before or at: return
"conftest.c", line 65: warning: syntax error: empty declaration
I would suggest:
--- configure.in (revision 305)
+++ configure.in (working copy)
@@ -355,12 +355,12 @@
AC_MSG_CHECKING([whether our compiler supports __func__])
AC_TRY_COMPILE([],
- [void foo() { const char *cp = __func__; }],
+ [const char *cp = __func__;],
AC_MSG_RESULT([yes]),
AC_MSG_RESULT([no])
AC_MSG_CHECKING([whether our compiler supports __FUNCTION__])
AC_TRY_COMPILE([],
- [void foo() { const char *cp = __FUNCTION__; }],
+ [const char *cp = __FUNCTION__;],
AC_MSG_RESULT([yes])
AC_DEFINE(__func__, __FUNCTION__,
[Define to appropriate substitue if compiler doesnt have
__func__]),
Yielding:
$ ./configure
[...]
checking whether our compiler supports __func__... yes
(from previous discussions with the GNUPG maintainers, my
understanding
is that __func__ is standard C99 while __FUNCTION__ is a GCC-ism)
______________________________________________________________________
__
3) event.h uses u_int8_t and friends instead of
uint8_t and friends
None of the Solaris system headers define the u_* variants.
Should all instances of u_* in event.h be changed to u* ?
______________________________________________________________________
__
4) http.c uses MIN() without declaring it as evdns.c does:
[EMAIL PROTECTED]:~/levent/trunk/libevent> gmake http.o
cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -g -c http.c
"http.c", line 871: warning: implicit function declaration: MIN
Fix:
--- http.c (revision 305)
+++ http.c (working copy)
@@ -73,6 +73,9 @@
#undef timeout_pending
#undef timeout_initialized
+#undef MIN
+#define MIN(a,b) ((a)<(b)?(a):(b))
+
#include "event.h"
#include "evhttp.h"
#include "log.h"
______________________________________________________________________
__
5) As Shanti pointed out in the aforementioned mailing list post, the
build breaks on libevent/sample/event-test:
[EMAIL PROTECTED]:~/levent/trunk/libevent/sample> gmake
/bin/bash ../libtool --tag=CC --mode=link cc -I../compat -o
event-test event-test.o ../libevent.la -lsocket
cc -I../compat -o .libs/event-test event-test.o ../.libs/
libevent.so -lsocket -R/usr/local/lib
Undefined first referenced
symbol in file
inet_aton ../.libs/libevent.so
ld: fatal: Symbol referencing errors. No output written to .libs/
event-test
Solaris needs -lresolv as well as -lsocket.
I would suggest:
--- configure.in (revision 305)
+++ configure.in (working copy)
@@ -36,6 +36,7 @@
dnl Checks for libraries.
AC_CHECK_LIB(socket, socket)
+AC_CHECK_LIB(resolv, inet_aton)
dnl Checks for header files.
AC_HEADER_STDC
--
Emil Mikulic, UNIX System Administrator | Ext: 55202
Technical Services Group | PGP: 8E4C5D35
Computer Science, RMIT University | Room 10.10.17
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
