9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: sqweek <sqweek@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] plan9 httpd/pegasus on unix?
Date: Fri, 29 Feb 2008 09:26:44 +0900	[thread overview]
Message-ID: <140e7ec30802281626x188aa366s1182a0313bc80aaf@mail.gmail.com> (raw)
In-Reply-To: <20080228172737.GA9702@nibiru.local>

On Fri, Feb 29, 2008 at 2:27 AM, Enrico Weigelt <weigelt@metux.de> wrote:
> * sqweek <sqweek@gmail.com> wrote:
>  > >  Did you ever try to building qmail ?
>  >
>  >  Yes. On linux and netbsd. With and without various patches. Works perfectly.
>
>  Well, you've probably got the netqmail port, which automatically patches
>  it's own sourcetree within the build process.

 Nope. qmail-1.03.tar.gz. On netbsd anyway - on linux I built it from
my package manager which... yes, uses netqmail. And I get the same TLS
error here as at work with qmail-1.03 so I guess I owe centOS an
apology.

>  > $ uname -p
>  > x86_64
>  > $ echo cc -m32 -O2 -include /usr/include/errno.h >conf-cc
>  > $ echo cc -m32 >conf-ld
>  > $ make
>
>  Well, this *very* unobvious and complex (instead of just passing $CC and
>  $LD to make), requires me to maintain additional logic, which woulnd't
>  be necessary, if DJB could write his makefiles in more standard and sane
>  ways ;-P

 The docs are a bit light on custom compilers, granted (probably as
they're irrelevant for 95% of users), but INSTALL does point you at
conf-users/conf-groups/conf-qmail. Doesn't take a genius to notice
conf-cc and conf-ld from there.
 DJB's makefiles have the dubious honour of probably being written
before such conventions existed. There is a reason he does it that way
- Makefile dependencies only work with the timestamps on files. If you
do it the "sane" way, then make has no information about the freshness
of the information in CC. Are there object files sitting around that
were built with an incompatible CC invocation?
 This is the motivation for DJB putting the commands into files
instead of using the environment or make variables. That way he can
have all the compilation rules depend on conf-cc so that should you
change it, everything gets rebuilt properly. Similarly with the other
conf- files - you don't need a make clean or anything after changing
them, just make and exactly what needs to get regenerated will get
regenerated. We're talking pretty marginal gains, obviously -
recompilation is not expensive. It's mainly an academic achievement -
having a *correct* Makefile.

>  >  Granted, the -include is a bitch and took me awhile to work out.
>
>  Actually, this is crap. Probably he just forgets the #include's.

 Yes. There is history here again. If you hunt around you'll find
posts from DJB complaining about unix (libc?) developers breaking
existing code by making errno not work without including errno.h.
Which made me somewhat surprised to hit this problem, but I guess
qmail-1.03 is old enough to be affected.

>  >  The sysroot requirement is a little harder to meet, but really just
>  > requires a mount --bind /tmp/sysroot/var/qmail /var/qmail. Or, if
>  > you're running qmail on the host and really can't afford to stop it
>  > for a minute or two, a custom setup rule based on hier.c (or use a
>  > chroot - oh if only lunix had private namespaces...).
>
>  chroot != sysroot.

 I'm well aware. If you were paying attention you'd notice I was
suggesting a chroot as a method of putting a directory from the
sysroot in the standard location without affecting the host system,
not suggesting you attempt to chroot into a cross-compiled root.
 And again, if lunix had learnt anything from plan9 this would be *trivial*.
-sqweek


  parent reply	other threads:[~2008-02-29  0:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-23 21:22 lejatorn
2008-02-23 21:34 ` erik quanstrom
2008-02-23 22:13 ` Skip Tavakkolian
2008-02-25 11:00 ` maht
2008-02-25 15:25   ` ron minnich
2008-02-25 16:26     ` John Barham
2008-02-27 15:52       ` Enrico Weigelt
2008-02-27 17:50         ` Steve Simon
2008-02-28  5:24         ` John Barham
2008-02-28  7:23         ` sqweek
2008-02-28 17:27           ` Enrico Weigelt
2008-02-28 19:23             ` Chad Dougherty
2008-02-29 14:43               ` Enrico Weigelt
2008-02-29  0:26             ` sqweek [this message]
2008-02-29 18:16               ` Enrico Weigelt
2008-02-29 18:18                 ` erik quanstrom
2008-02-29 18:37                 ` Uriel
2008-02-29 18:44                 ` Russ Cox
2008-02-25 16:30     ` lejatorn
2008-02-25 16:48       ` Kernel Panic
2008-02-25 19:03 ` Uriel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=140e7ec30802281626x188aa366s1182a0313bc80aaf@mail.gmail.com \
    --to=sqweek@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).