Re: [Monotone-devel] list branches on server?
Timothy Brownawell writes: > On Sat, 2009-08-22 at 21:10 -0600, Derek Scherger wrote: >> On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell >> wrote: > >> >> * version skew wrt libstdc++, eg boost and monotone have >> different ideas of what exactly an std::string looks like >> >> Fantastic. Can you elaborate on this? I wonder how it's even possible >> when boost is built with the same libstdc++ as monotone on my machine? > > Say your distribution is on gcc 3.4 so that's what boost is compiled > with, and the binary on our site was compiled with 4.0. Or even if you > compile it yourself, but you've installed a later version of gcc than > the version that your distro is currently using. This applies to any library written in C++, not just Boost. Botan is in C++. And it applies to C libraries as well, but apparently they are more stable? In general, anyone experimenting with new versions of compilers has to be aware of such issues, and compile everything consistently. The mtn binary for Linux on the mtn website should be more fully described (compiler version, required dynamic library versions), so people can do the right thing with it. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
Timothy Brownawell writes: > On Sat, 2009-08-22 at 21:10 -0600, Derek Scherger wrote: >> On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell >> wrote: > >> >> * version skew wrt libstdc++, eg boost and monotone have >> different ideas of what exactly an std::string looks like >> >> Fantastic. Can you elaborate on this? I wonder how it's even possible >> when boost is built with the same libstdc++ as monotone on my machine? > > Say your distribution is on gcc 3.4 so that's what boost is compiled > with, and the binary on our site was compiled with 4.0. Or even if you > compile it yourself, but you've installed a later version of gcc than > the version that your distro is currently using. This applies to any library written in C++, not just Boost. Botan is in C++. And it applies to C libraries as well, but apparently they are more stable? In general, anyone experimenting with new versions of compilers has to be aware of such issues, and compile everything consistently. The mtn binary for Linux on the mtn website should be more fully described (compiler version, required dynamic library versions), so people can do the right thing with it. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
Derek Scherger writes: > Another thought on this that I've had floating around for a while is that > perhaps rather than starting a second process and running netsync over stdio > we could have two separate database instances open and sync between them > from within a single process. I haven't looked at this in any detail at all > so it might just be a crazy idea, but I think it would avoid all of the > windows related network issues. Maybe some of the refactoring that zack and > markus did a while ago relating to app_state, options and database arguments > in various api's would make the idea of having two open database objects > less crazy? That solves the file: problem on Win32. But it doesn't allow ssh: to a Win32 server. Although, with a Win32 server, you're more likely to be exporting a file share containing the database anyway. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
Am 23.08.2009 14:20, schrieb Stephen Leake:
> The mtn binary for Linux on the mtn website should be more fully
> described (compiler version, required dynamic library versions), so
> people can do the right thing with it.
What is "the right thing" besides downloading, unpacking, running?
Also, it describes itself pretty good:
$ ./mtn-0.44-linux-x86 version --full
monotone 0.44 (base revision: 7a4832143b3146ca89f5cb91e0e571d05e29d4b9)
Running on : Linux 2.6.29.6-217.2.8.fc11.i586 #1 SMP Sat Aug 15
00:44:39 EDT 2009 i686
C++ compiler: GNU C++ version 4.3.2
C++ standard library: GNU libstdc++ version 20080905
Boost version : 1_34_1
SQLite version : 3.5.9 (compiled against 3.5.9)
Lua version : Lua 5.1
PCRE version: 7.6 2008-01-28 (compiled against 7.6)
Botan version : 1.7.8 (compiled against 1.7.8)
[...]
It is a binary for ia32 Linux that only needs glibc 2.3 (and most likely
also runs on 64bit Linux, given it provides a 32bit glibc):
$ ldd ./mtn-0.44-linux-x86
linux-gate.so.1 => (0x00e75000)
libdl.so.2 => /lib/libdl.so.2 (0x0048)
libm.so.6 => /lib/libm.so.6 (0x00456000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00487000)
libc.so.6 => /lib/libc.so.6 (0x002e3000)
/lib/ld-linux.so.2 (0x002bf000)
$ readelf -s ./mtn-0.44-linux-x86 |
sed -r '/GLIBC/{s,^.*@(GLIBC_[0-9.]+).*$,\1,;n};d' | sort -u
GLIBC_2.0
GLIBC_2.1
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.4
GLIBC_2.3
What exactly would you suggest writing on the website?
Regards,
Thomas
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sun, 2009-08-23 at 08:20 -0400, Stephen Leake wrote: > Timothy Brownawell writes: > > > On Sat, 2009-08-22 at 21:10 -0600, Derek Scherger wrote: > >> On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell > >> wrote: > > > >> > >> * version skew wrt libstdc++, eg boost and monotone have > >> different ideas of what exactly an std::string looks like > >> > >> Fantastic. Can you elaborate on this? I wonder how it's even possible > >> when boost is built with the same libstdc++ as monotone on my machine? > > > > Say your distribution is on gcc 3.4 so that's what boost is compiled > > with, and the binary on our site was compiled with 4.0. Or even if you > > compile it yourself, but you've installed a later version of gcc than > > the version that your distro is currently using. > > This applies to any library written in C++, not just Boost. Botan is > in C++. > > And it applies to C libraries as well, but apparently they are > more stable? > > In general, anyone experimenting with new versions of compilers has to > be aware of such issues, and compile everything consistently. Yes... I guess what made this a "boost issue" is that boost was the only library we didn't bundle at the time. > The mtn binary for Linux on the mtn website should be more fully > described (compiler version, required dynamic library versions), so > people can do the right thing with it. Which would require people to know what gcc version their distro is using. This seems reasonable to expect of people coding in C or C++, but what of everyone else (particularly if they can't do "gcc --version" because it isn't installed)? Do you know of a way to detect at runtime which compiler version was used for the libraries? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Merging branch to allow duplicate key names, have certs use key hash
On Sun, Aug 23, 2009 at 07:43:04AM +0200, Richard Levitte wrote: > In message <1250815028.4392.1.ca...@localhost> on Thu, 20 Aug 2009 19:37:08 > -0500, Timothy Brownawell said: > > tbrownaw> On Fri, 2009-08-14 at 05:04 +, Timothy Brownawell wrote: > tbrownaw> > I think branch net.venge.monotone.keys-by-hash is ready now. > tbrownaw> > > tbrownaw> > The central change is that certs contain a key hash > tbrownaw> > instead of a key name, to get rid of the problem with key > tbrownaw> > collisions. > tbrownaw> > tbrownaw> > This does require a netsync flag day, because certs on the > tbrownaw> > wire contain a key hash instead of a key name now (just > tbrownaw> > like certs in the db). > tbrownaw> > tbrownaw> This is merged now. > > Cool! > > I wonder, what do you propose for a flag day for our repository? > (and lets not forget to announce it clearly on http://monotone.ca/ and > to make sure there's ample time for people to adapt, rebuild, yada > yada yada) Since it seems to be a flag day for the netsync protocol, and not for the database format (have I got this wrong) it would be possible to set up two monotone servers (one for the old and one for the new protocol) on a machine with two IP numbers, both operating on the very same copy of the data base no. the server locks the data base, doesn't it. Then have two servers for the general public to use during transition, and during that time, someone, somewhere, regularly syncs one local copy with each server (using a different version on monotone to access each server). Then there will be a transition period of parallel operation, during which users can sync and rebuild their monotones at leisure. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Merging branch to allow duplicate key names, have certs use key hash
On Sun, 2009-08-23 at 09:54 -0400, hend...@topoi.pooq.com wrote: > On Sun, Aug 23, 2009 at 07:43:04AM +0200, Richard Levitte wrote: > > In message <1250815028.4392.1.ca...@localhost> on Thu, 20 Aug 2009 19:37:08 > > -0500, Timothy Brownawell said: > > > > tbrownaw> On Fri, 2009-08-14 at 05:04 +, Timothy Brownawell wrote: > > tbrownaw> > I think branch net.venge.monotone.keys-by-hash is ready now. > > tbrownaw> > > > tbrownaw> > The central change is that certs contain a key hash > > tbrownaw> > instead of a key name, to get rid of the problem with key > > tbrownaw> > collisions. > > tbrownaw> > > tbrownaw> > This does require a netsync flag day, because certs on the > > tbrownaw> > wire contain a key hash instead of a key name now (just > > tbrownaw> > like certs in the db). > > tbrownaw> > > tbrownaw> This is merged now. > > > > Cool! > > > > I wonder, what do you propose for a flag day for our repository? > > (and lets not forget to announce it clearly on http://monotone.ca/ and > > to make sure there's ample time for people to adapt, rebuild, yada > > yada yada) > > Since it seems to be a flag day for the netsync protocol, and not for > the database format (have I got this wrong) it would be possible to set > up two monotone servers (one for the old and one for the new > protocol) on a machine with two IP numbers, both operating on the very > same copy of the data base no. the server locks the data base, > doesn't it. There is a schema change, but it doesn't require history to be rebuilt. > Then have two servers for the general public to use during transition, > and during that time, someone, somewhere, regularly syncs one local copy > with each server (using a different version on monotone to access > each server). > > Then there will be a transition period of parallel operation, during > which users can sync and rebuild their monotones at leisure. > > -- hendrik > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sun, Aug 23, 2009 at 09:15:32AM -0500, Timothy Brownawell wrote: > On Sun, 2009-08-23 at 08:20 -0400, Stephen Leake wrote: > > Timothy Brownawell writes: > > > > > On Sat, 2009-08-22 at 21:10 -0600, Derek Scherger wrote: > > >> On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell > > >> wrote: > > > > > >> > > >> * version skew wrt libstdc++, eg boost and monotone have > > >> different ideas of what exactly an std::string looks like > > >> > > >> Fantastic. Can you elaborate on this? I wonder how it's even possible > > >> when boost is built with the same libstdc++ as monotone on my machine? > > > > > > Say your distribution is on gcc 3.4 so that's what boost is compiled > > > with, and the binary on our site was compiled with 4.0. Or even if you > > > compile it yourself, but you've installed a later version of gcc than > > > the version that your distro is currently using. > > > > This applies to any library written in C++, not just Boost. Botan is > > in C++. > > > > And it applies to C libraries as well, but apparently they are > > more stable? > > > > In general, anyone experimenting with new versions of compilers has to > > be aware of such issues, and compile everything consistently. > > Yes... I guess what made this a "boost issue" is that boost was the only > library we didn't bundle at the time. > > > The mtn binary for Linux on the mtn website should be more fully > > described (compiler version, required dynamic library versions), so > > people can do the right thing with it. > > Which would require people to know what gcc version their distro is > using. This seems reasonable to expect of people coding in C or > C++, but what of everyone else (particularly if they can't do > "gcc --version" because it isn't installed)? > > Do you know of a way to detect at runtime which compiler version was > used for the libraries? Well. at the very least they'd have an idea where the problem lay. And our wiki could end up holding some distribution-dependent information (like which gcc the libraries of horny-hedgehog (or whatever) were compiled with) when we become aware of it.. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
Thomas Moschny writes:
> Am 23.08.2009 14:20, schrieb Stephen Leake:
>> The mtn binary for Linux on the mtn website should be more fully
>> described (compiler version, required dynamic library versions), so
>> people can do the right thing with it.
>
> What is "the right thing" besides downloading, unpacking, running?
Not doing that, because you know it won't work. Instead, investigating
a distribution, or downloading the source.
> Also, it describes itself pretty good:
>
> $ ./mtn-0.44-linux-x86 version --full
> monotone 0.44 (base revision: 7a4832143b3146ca89f5cb91e0e571d05e29d4b9)
> Running on : Linux 2.6.29.6-217.2.8.fc11.i586 #1 SMP Sat Aug 15
> 00:44:39 EDT 2009 i686
> C++ compiler: GNU C++ version 4.3.2
> C++ standard library: GNU libstdc++ version 20080905
> Boost version : 1_34_1
> SQLite version : 3.5.9 (compiled against 3.5.9)
> Lua version : Lua 5.1
> PCRE version: 7.6 2008-01-28 (compiled against 7.6)
> Botan version : 1.7.8 (compiled against 1.7.8)
> [...]
>
> It is a binary for ia32 Linux that only needs glibc 2.3 (and most likely
> also runs on 64bit Linux, given it provides a 32bit glibc):
>
> $ ldd ./mtn-0.44-linux-x86
> linux-gate.so.1 => (0x00e75000)
> libdl.so.2 => /lib/libdl.so.2 (0x0048)
> libm.so.6 => /lib/libm.so.6 (0x00456000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x00487000)
> libc.so.6 => /lib/libc.so.6 (0x002e3000)
> /lib/ld-linux.so.2 (0x002bf000)
>
> $ readelf -s ./mtn-0.44-linux-x86 |
> sed -r '/GLIBC/{s,^.*@(GLIBC_[0-9.]+).*$,\1,;n};d' | sort -u
> GLIBC_2.0
> GLIBC_2.1
> GLIBC_2.1.3
> GLIBC_2.2
> GLIBC_2.2.4
> GLIBC_2.3
>
> What exactly would you suggest writing on the website?
Something like this:
This is a binary for ia32 Linux built with GNU C++ version 4.3.2,
that only needs glibc 2.3 dynamic libraries, and most likely also
runs on a 64bit Linux that provides a 32bit glibc. The best way to
find out if it will work for you is to download it, and run
'mtn-0.44-linux-x86 version'. If that reports no errors, it should
work in general.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sun, Aug 23, 2009 at 7:15 AM, Timothy Brownawell wrote: >> This applies to any library written in C++, not just Boost. Botan is >> in C++. >> >> And it applies to C libraries as well, but apparently they are >> more stable? >> >> In general, anyone experimenting with new versions of compilers has to >> be aware of such issues, and compile everything consistently. > > Yes... I guess what made this a "boost issue" is that boost was the only > library we didn't bundle at the time. Also, boost pushes the boundaries of C++ a lot more than any other C++ library -- that's what it's *for*, kinda. I expect Botan to be a lot less trouble that way. C libraries do tend to be more stable. > Do you know of a way to detect at runtime which compiler version was > used for the libraries? "mtn version --full" prints at least some of the necessary information. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
Timothy Brownawell writes: > On Sun, 2009-08-23 at 08:20 -0400, Stephen Leake wrote: >> Timothy Brownawell writes: >> >> > On Sat, 2009-08-22 at 21:10 -0600, Derek Scherger wrote: >> >> On Sat, Aug 22, 2009 at 1:59 PM, Timothy Brownawell >> >> wrote: >> > >> >> >> >> * version skew wrt libstdc++, eg boost and monotone have >> >> different ideas of what exactly an std::string looks like >> >> >> >> Fantastic. Can you elaborate on this? I wonder how it's even possible >> >> when boost is built with the same libstdc++ as monotone on my machine? >> > >> > Say your distribution is on gcc 3.4 so that's what boost is compiled >> > with, and the binary on our site was compiled with 4.0. Or even if you >> > compile it yourself, but you've installed a later version of gcc than >> > the version that your distro is currently using. >> >> This applies to any library written in C++, not just Boost. Botan is >> in C++. >> >> And it applies to C libraries as well, but apparently they are >> more stable? >> >> In general, anyone experimenting with new versions of compilers has to >> be aware of such issues, and compile everything consistently. > > Yes... I guess what made this a "boost issue" is that boost was the only > library we didn't bundle at the time. > >> The mtn binary for Linux on the mtn website should be more fully >> described (compiler version, required dynamic library versions), so >> people can do the right thing with it. > > Which would require people to know what gcc version their distro is > using. This seems reasonable to expect of people coding in C or > C++, but what of everyone else (particularly if they can't do > "gcc --version" because it isn't installed)? Good point. > Do you know of a way to detect at runtime which compiler version was > used for the libraries? No, unless there is a global naming convention on libraries so that the version numbers are distinct for different compiler versions. Which seems unlikely. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [PATCH] Broken migration code? (Merging branch to allow duplicate key names, have certs use key hash)
On Thu, 2009-08-20 at 19:37 -0500, Timothy Brownawell wrote:
> On Fri, 2009-08-14 at 05:04 +, Timothy Brownawell wrote:
> > I think branch net.venge.monotone.keys-by-hash is ready now.
> >
> > The central change is that certs contain a key hash instead of a key
> > name, to get rid of the problem with key collisions.
>
> > This does require a netsync flag day, because certs on the wire contain
> > a key hash instead of a key name now (just like certs in the db).
>
> This is merged now.
...and it looks like I forgot to make the migration code fix the cert
hashes (which AFAICT are only used for netsync, so possible wierdness if
people 'db migrate' with out-of-sync db's and then try to sync the
migrated certs).
I'm getting make errors[1] when I try to build even a clean checkout
right now, so could someone try this patch and check that the
lua-testsuite.lua change makes the testsuite fail, and the other changes
make it pass again?
[1] Makefile:897: *** Recursive variable `V_bcxx_' references itself
(eventually). Stop.
$ mtn diff
#
# old_revision [aebb88e9030d0e5616d1974a1ed9755cf176ffea]
#
# patch "cert.cc"
# from [9217fc9e7d471997b0761e4928bbf5eed0e220e0]
#to [0ea75effef93704ece9fba001901ee62ed13e249]
#
# patch "lua-testsuite.lua"
# from [e28a4e630a460bcca1a2d9023a2a898c1e77670a]
#to [69fbf7b5f0a6bd3899efec21a992c841595109c8]
#
# patch "migrate_schema.cc"
# from [aea2f5b02394463bb93f868724173d10f9b865a3]
#to [0f663641b253e0b87e1422f39491662a1d4cb642]
#
--- cert.cc 9217fc9e7d471997b0761e4928bbf5eed0e220e0
+++ cert.cc 0ea75effef93704ece9fba001901ee62ed13e249
@@ -126,23 +126,23 @@ cert::hash_code(id & out) const
void
cert::hash_code(id & out) const
{
- base64 sig_encoded(encode_base64(this->sig));
- base64 val_encoded(encode_base64(this->value));
- string ident_encoded(encode_hexenc(this->ident.inner()(),
- this->ident.inner().made_from));
+ //base64 sig_encoded(encode_base64(this->sig));
+ //base64 val_encoded(encode_base64(this->value));
+ //string ident_encoded(encode_hexenc(this->ident.inner()(),
+ // this->ident.inner().made_from));
string tmp;
- tmp.reserve(4 + ident_encoded.size()
- + this->name().size() + val_encoded().size()
- + this->key.inner()().size() + sig_encoded().size());
- tmp.append(ident_encoded);
+ tmp.reserve(4 + ident.inner()().size()
+ + this->name().size() + value().size()
+ + this->key.inner()().size() + sig().size());
+ tmp.append(ident.inner()());
tmp += ':';
tmp.append(this->name());
tmp += ':';
- append_without_ws(tmp, val_encoded());
+ append_without_ws(tmp, value());
tmp += ':';
tmp.append(this->key.inner()());
tmp += ':';
- append_without_ws(tmp, sig_encoded());
+ append_without_ws(tmp, sig());
data tdat(tmp, origin::internal);
calculate_ident(tdat, out);
--- lua-testsuite.lua e28a4e630a460bcca1a2d9023a2a898c1e77670a
+++ lua-testsuite.lua 69fbf7b5f0a6bd3899efec21a992c841595109c8
@@ -272,7 +272,10 @@ function check_same_db_contents(db1, db2
file = trim(file)
check_same_stdout(mtn("--db", db1, "automate", "get_file", file),
mtn("--db", db2, "automate", "get_file", file))
- end
+ end
+
+ check_same_stdout(mtn("--db", db1, "db", "execute", "select hex(hash) from
revision_certs"),
+ mtn("--db", db2, "db", "execute", "select hex(hash) from
revision_certs"))
end
-- maybe these should go in tester.lua?
--- migrate_schema.cc aea2f5b02394463bb93f868724173d10f9b865a3
+++ migrate_schema.cc 0f663641b253e0b87e1422f39491662a1d4cb642
@@ -728,7 +728,8 @@ char const migrate_certs_to_key_hash[] =
"CREATE INDEX revision_certs__revision_id ON revision_certs (revision_id);\n"
"INSERT INTO revision_certs(hash, revision_id, name, value, keypair_id,
signature)\n"
- "SELECT a.hash, a.id, a.name, a.value, b.id, a.signature\n"
+ "SELECT sha1(':', a.id, a.name, a.value, b.id, a.signature), "
+ " a.id, a.name, a.value, b.id, a.signature\n"
"FROM revision_certs_tmp a JOIN public_keys b\n"
"ON a.keypair = b.name;\n"
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Broken migration code? (Merging branch to allow duplicate key names, have certs use key hash)
Timothy Brownawell writes: > I'm getting make errors[1] when I try to build even a clean checkout > right now ... > > > [1] Makefile:897: *** Recursive variable `V_bcxx_' references itself > (eventually). Stop. I get that same error on Debian, but not on Windows. I think the problem is that AM_DEFAULT_VERBOSITY is not being set anywhere in the Makefile on Debian. But I don't know why; it is set on Windows. So a workaround is to add a line to the Makefile: AM_DEFAULT_VERBOSITY = 1 -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 11:55:40PM -0600, Derek Scherger wrote: > > does not have any SSL implementation. But shouldn't that be done by, > > or on top of, Botan rather than at a lower level? > > Very possibly yes. I haven't looked at how botan might help us here, if at > all. Jack, can you comment? > A while ago I wrote a SSL/TLS library on top of botan. I haven't had the time/energy/inspiration to work on it much in a number of years, but it handles the basic protocol fairly well. http://randombit.net/code/ajisai -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Broken migration code? (Merging branch to allow duplicate key names, have certs use key hash)
On Sun, Aug 23, 2009 at 7:08 PM, Stephen Leake wrote: >> [1] Makefile:897: *** Recursive variable `V_bcxx_' references itself >> (eventually). Stop. > > I get that same error on Debian, but not on Windows. > > I think the problem is that AM_DEFAULT_VERBOSITY is not being set > anywhere in the Makefile on Debian. But I don't know why; it is set on > Windows. Is it possibly that you have automake 1.11 on Windows but an older version on Debian? I should have tested with older versions. Possible proper fix: -m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES]) +m4_ifdef([AM_SILENT_RULES], + [AM_SILENT_RULES], + [AM_DEFAULT_VERBOSITY=1 + AC_SUBST([AM_DEFAULT_VERBOSITY])]) in configure.ac. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
