Hi,

just made a Solaris 10 sparc package for UW imap-2006b (using Studio 11
compiler), but using -xarch=v9 aka 64bit seems to break imapd over SSL
(v8 aka 32bit works): connection timeouts. Traces show, that in the
64bit version tcp_serverport() always returns -1 instead of 993 (as the
32bit version does). So is it possible, that the unix/ip_*|tcp_* source
is not 64bit safe? Or do you think, it might be a compiler problem ?

BTW: for reproduction e.g.:

cd c-client;make soc EXTRACFLAGS='-g -xarch=v9
-I/tmp/build/root4build/usr/include -I/usr/sfw/include -KPIC'\
EXTRALDFLAGS='-L/tmp/build/root4build/usr/lib/sparcv9
-L/usr/sfw/lib/sparcv9'\
EXTRADRIVERS='mbox'\
EXTRAAUTHENTICATORS=''\
PASSWDTYPE=std SSLTYPE=unix IP=4\

ln -s os_soln.h os_sol.h
make build EXTRACFLAGS='-g -xarch=v9
-I/tmp/build/root4build/usr/include -I/usr/sfw/include -KPIC'
EXTRALDFLAGS='-L/tmp/build/root4build/usr/lib/sparcv9
-L/usr/sfw/lib/sparcv9' EXTRADRIVERS='mbox' EXTRAAUTHENTICATORS=''
PASSWDTYPE=std SSLTYPE=unix IP=4 `cat SPECIALS` OS=sol \
SIGTYPE=psx CHECKPW=psx CRXTYPE=nfs \
SPOOLDIR=/var/spool MAILSPOOL=/var/mail \
ACTIVEFILE=/var/news/active \
RSHPATH=/usr/bin/rsh \
BASECFLAGS= \
BASELDFLAGS="-lsocket -lnsl -lgen" \
RANLIB=true CC=cc
....

In general, 64-bit builds are untested and not recommended in UW imapd.
There is generally not much benefit to a 64-bit build.

I do not have easy access to a Solaris system, and there's a long history
of Solaris being troublesome to support. Solaris is SVR4 based, which is
not a recommended platform due to its deficiencies (Linux and BSD are
recommended platforms).

However, there may be a simple explanation and fix for your problem.

By default, Solaris builds use IPv4 only code. If getsockname() returns
an IPv6 socket, that would cause the -1 port that you experienced.

Try adding IP=6 to your make command (you'll need to "make clean" first).
That'll select the IPv6 code which is also IPv4 savvy.

That may be the magic bullet that solves the problem.

Good luck!

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Mark Crispin wrote:
> In general, 64-bit builds are untested and not recommended in UW imapd.


> There is generally not much benefit to a 64-bit build.

Yes, I know. But since I do not want to package each SW twice, and some SW
really benefits from 64bit, but unfortunately one can't mix 32 and 64bit
objects/libs, I decided to make all packages 64bit, only.

> Solaris is SVR4 based,
> which is not a recommended platform due to its deficiencies (Linux and
> BSD are recommended platforms).

Well, have not really a choice ;-)

> However, there may be a simple explanation and fix for your problem.
>
> By default, Solaris builds use IPv4 only code. If getsockname() returns
> an IPv6 socket, that would cause the -1 port that you experienced.
>
> Try adding IP=6 to your make command (you'll need to "make clean"
> first). That'll select the IPv6 code which is also IPv4 savvy.
>
> That may be the magic bullet that solves the problem.

No - same problem. Must be something different...
BTW: What is the easiest way to programatically enable the tcbdebug
stuff, so that I can do some "printf" debugging, when I find the time
for it ?

Regards,
jens.

On Fri, 13 Oct 2006, Jens Elkner wrote:
>> Try adding IP=6 to your make command (you'll need to "make clean" first).
>> That'll select the IPv6 code which is also IPv4 savvy.
> No - same problem. Must be something different...

Hmm. This suggests that it's not getting the correct value for sa_family
from the sockaddr. Maybe some includes need to be different if you do
64-bit builds on Solaris.

I don't see what you can't make an exception for imapd and build it
32-bit.

> BTW: What is the easiest way to programatically enable the tcbdebug stuff, so
> that I can do some "printf" debugging, when I find the time for it ?

The tcpdebug stuff only s in client code, not server code. You'll be
better off just doing logging code (via syslog(), not printf()) yourself.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Mark Crispin wrote:
> On Fri, 13 Oct 2006, Jens Elkner wrote:
>
> Hmm. This suggests that it's not getting the correct value for
> sa_family from the sockaddr.

Yepp.

> I don't see what you can't make an exception for imapd and build it 32-bit.
As I said: XOR - e.g. PHP+libc-client.so (maintainance)

>> BTW: What is the easiest way to programatically enable the tcbdebug
>> stuff, so that I can do some "printf" debugging, when I find the time
>> for it ?
>
> The tcpdebug stuff only s in client code, not server code. You'll
> be better off just doing logging code (via syslog(), not printf())
> yourself.

Hmmm, ok - may be it isn't worth to debug/fix it (already spent to much
time on this). After 10 years of WU-IMAP may be it's time to change
something and to have a look at cyrus ...

Thanx a lot,
jens.

In <Pine.WNT.4.65.0610121505590.2320@Tomobiki-Cho.CAC.Washington.EDU> Mark Crispin <MRC@CAC.Washington.EDU> writes:

>I do not have easy access to a Solaris system, and there's a long history
>of Solaris being troublesome to support.

why?

>Solaris is SVR4 based, which is
>not a recommended platform due to its deficiencies

what deficiencies?


Willi

On Fri, 13 Oct 2006, Willi Burmeister wrote:
> >I do not have easy access to a Solaris system, and there's a long history
> >of Solaris being troublesome to support.
> why?

I don't want to go into detail; this newsgroup is not the appropriate
place for Solaris-bashing. Suffice it to say that Solaris has a long
history of incompatibility with other UNIX-like systems and with other
versions of Solaris.

> >Solaris is SVR4 based, which is
> >not a recommended platform due to its deficiencies
> what deficiencies?

The deficiencies impact performance and reliability. I know of sites that
have fixed their IMAP performance problems simply by replacing SVR4 based
systems with (less expensive!) Linux systems.

SVR4 only has POSIX style fcntl() locking. The BSD man pages call the
semantics of POSIX locking "completely stupid"; I don't disagree. I have
quoted the relevant paragraph from the BSD man page many times already; I
hope that I don't have to do so again. UW imapd is obliged to do
considerable more work on SVR4 systems than it does on BSD and Linux
systems which offer flock() locking as an alternative to POSIX locking.

Many (most?) SVR4 filesystems are poor performers compared to BSD and
Linux filesystems.

I do not recommend Solaris, or any other SVR4 based system (AIX, HP-UX,
etc.) as a platform for an IMAP server. This is not just for UW imapd.
Linux and BSD are more suitable platforms for other IMAP server
implementations as well. Other IMAP server implementations may not be as
severely impacted by the choice of SVR4; but I can't imagine any IMAP
server implementation performing better on SVR4 than on Linux or BSD.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Oct 12, 5:16 pm, Jens Elkner <elkner+news...@cs.uni-magdeburg.de>
wrote:
> Mark Crispin wrote:
> > There is generally not much benefit to a 64-bit build.
>
> Yes, I know. But since I do not want to package each SW twice, and some SW
> really benefits from 64bit, but unfortunately one can't mix 32 and 64bit
> objects/libs, I decided to make all packages 64bit, only.

Nothing personal, but I find that bizarre. I mean, the only files for
which you need separate 32bit and 64bit copies are libraries. You
would rather replace your software or run software that hasn't been
fully tested for 64bit compilation than keep around two copies to some
libraries. (How many non-Sun libraries does UW-imap actually require?)
What about programs that run *faster* as 32bit binaries because the
cache-footprint of their data is smaller?

Nevermind, it's your call. You'll even be doing a service to the
community by reporting problems that developers may not have the
hardware to check themselves.


Philip Guenther