On Thu, Dec 11, 2003 at 10:26:14AM +0900, Stephen J. Turnbull wrote:
> I had some trouble building coda with GCC 3.3.2 (Debian; further
> details on request), and also with autoconf in lwp.  I've got other
> runtime problems in a separate message, but if you build via
> debian/rules, the binaries get stripped.  This is near-current CVS
> (the patches below are against a workspace updated two days ago).

Which is according to 'Debian policy'. You could use the 'standard'
environment variable to compile with debug symbols and avoid stripping.

    export DEB_BUILD_OPTIONS=debug,nostrip

Jan

> 1. Auto* tools 2.58 (maybe this is automake 1.7?) seems to want
> AC_CONFIG_HEADERS, not AM_CONFIG_HEADER, in configure.in.  I'm not
> sure why this only affects lwp.  I have not yet tested on a fresh

The others have had releases after the time that automake/autoconf
started breaking our configure scripts.

> 2. I'm commenting out the dh_strip in all my debian/rules files now,
> but I think that (for CVS) not stripping should be the default even if
> you're building .debs.  Let the downstream Debian maintainer do the
> stripping for production releases.  Patch is "obviously correct."  ;-)

But using the DEB_BUILD_OPTIONS environment variable (should) do the
right thing for all debian packages. It would be kind of strange if
everyone else defaults to stripped binaries with a special variable to
turn it on, while we default to debug binaries with a flag to turn it
off. On the other hand, there are still enough unusual crashes that
still need to be tracked down to provide binaries with debug symbols.

> 3. In Linux (at least, it looks to me like the same problem occurs in
> the BSD kernel code too) the macro _IOWR expands to take sizeof of its
> third argument.  As you see below, when CIOC_KERNEL_VERSION gets
> expanded, this results in the expression "sizeof (sizeof (int))" which
> is semantically silly (although probably correct on 32-bit CPUs, it's
> probably wrong on many 64-bit boxen where int is often 32 bits but
> size_t is unsigned long and therefore 64 bits).

Hmm, never noticed that, thanks.

Jan