Re: [Monotone-devel] Re: glibc 2.2. version?

[Nathaniel Smith]

On Thu, Mar 24, 2005 at 01:58:32PM -0500, Deliverable Mail wrote:
> Yes, yes, yes, yes!
> Yes!  Static, please!  Just some, no need for extra care stuff, for
> "linux" would be fine.  Darcs static is a godsend -- I got it before I
> was interested enough to get a Haskell compiler and compile it.  And I
> did compile _and_ run it, unlike monotone in C++.  So much for
> portability...

Yes, yes, we'd love to distribute static versions.  The problem is
that _there is no longer such a thing as a static build with recent
glibc versions_, because the glibc maintainers do not think supporting
this case is important.  If anyone out there makes a static build,
then yay.  I just tried, and couldn't even get a binary out (even
ignoring the warning messages about how even though this build is
static it will still require the same versions of libc be installed at
run time as if it were dynamic).  Sorry.  We fought this and lost.

> (Is there an option to set --db=<smth> as default? 

Working dirs remember which database they're associated with.  There's
currently no way to set a global default --db; not clear if that would
be useful or not...

> What is the treatment of identical changes conflict?)

Two identical changes are detected as such, and merge cleanly.

> The problem is most likely with crypto++ build, which does build and
> then fails validation, just like monotone buids and silently, um,
> loudly fails to even create a db.  I reported the bug to Wei Dai. 
> BTW, his distro doesn't even build into a separate dir -- had to make
> a Makefile for that.  And it fails with all the g++'s I got.  It
> doesn't even compile with good ol' 2.95.3.  I believe its flakiness is
> a problem for monotone.  If monotone chose to use it, it better work
> around/with it...

This is why we ship our own version of crypto++ (with, IIRC, some bug
fixes in it), and always build with either -O0 or "-O2
-fno-strict-aliasing".  I still don't think you've said whether you
are
  - using the built in version of crypto++
  - compiling with -fno-strict aliasing
? Failing to do either of these things could well explain your
problems.

(We also have plans to switch away from crypto++, perhaps by 0.18, but
this hasn't happened yet.)

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender