Re: [Monotone-devel] hang on Win32/MinGW with sync file:
Matthew Gregan [EMAIL PROTECTED] writes: Ok. Can you send me that code? I'm at the point of implementing some simple standalone debug code. Maybe I could start with yours. Attached. Try not to be too shocked, it's a fearsome trainwreck of write-only test code. Looks like the secret is to call GetStdHandle instead of just using STDIN_FILENO. At least, that gets past the select on non-socket problem; now I have other problems. Making progress ... -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] Bug#455646: FTBFS with GCC 4.3: missing #includes
On Dec 10, 2007 7:41 PM, Martin Michlmayr [EMAIL PROTECTED] wrote: Package: monotone Version: 0.37-4 Usertags: ftbfs-gcc-4.3 Your package fails to build with GCC 4.3. Version 4.3 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. With my upstream hat on, I've committed *partial* fixes for this problem. (These will appear in 0.39, due out in probably a month.) I am cc:ing you back and monotone-devel as well, because there are still some problems that I need help with: 1) declaration changes meaning of symbol errors. I see two of these: roster.cc:3503: error: declaration of 'virtual voidunnamed::a_scalar::set(const revision_id, unnamed::scalar_val, const std::setrevisionhexencid , std::lessrevisionhexencid , std::allocatorrevisionhexencid , roster_t, marking_map)' bits/stl_set.h:95: error: changes meaning of 'set' from 'class std::setrevisionhexencid , std::lessrevisionhexencid , std::allocatorrevisionhexencid ' and boost/circular_buffer_base.hpp:502: error: declaration of 'typedef class boost::reverse_iteratorboost::cb_details::cb_iteratorboost::circular_bufferT, Alloc, boost::cb_details::cb_nonconst_traitsAlloc boost::circular_bufferT, Alloc::reverse_iterator' boost/iterator/reverse_iterator.hpp:23: error: changes meaning of 'reverse_iterator' from 'class boost::reverse_iteratorboost::cb_details::cb_iteratorboost::circular_bufferT, Alloc, boost::cb_details::cb_nonconst_traitsAlloc ' (note: boost::circular_buffer is an unofficial experimental boost module that we picked up a long time ago - don't go looking for it in the official boost packages.) I have never seen this error before. My immediate reaction is that I have no idea what's going on in boost (but who does?) and that the code in roster.cc ought to be valid - but I am by no means a C++ expert. I was not able to construct a cut-down version of the roster.cc code that provokes the same error; perhaps I'll get around to delta-minimizing one from the real code, but I doubt I'll have time soon. 2) sqlite/vdbeaux.c:2212: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1746 GCC bug. Should be reproducible with the official Debian sqlite package. I do not have time to file a GCC bug report. 3) backward/auto_ptr.h: In static member function 'static bool Botan::DL_Group::generate_dsa_primes(Botan::BigInt , Botan::BigInt, Botan::u32bit, Botan::u32bit, const Botan::MemoryRegionunsigned char)': backward/auto_ptr.h:177: warning: 'hash.std::auto_ptrBotan::HashFunction::_M_ptr' is used uninitialized in this function botan/dsa_gen.cpp:57: note: 'hash.std::auto_ptrBotan::HashFunction::_M_ptr' was declared here Looks spurious; the variable in question is declared with a constructor expression. (I am ignorant of what is going on inside auto_ptr though.) Note also to monotone-devel: some of the changes were in netxx. That's the one we basically own at this point because its upstream died, right? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Information for binary uploaders
Stephen Leake wrote: Cygwin is also 32 bit. Yes, and won't be different anytime soon. Perhaps it should be: o Windows (32 bit) _native_ _cygwin_ There are people running 64 bit Windows now. I assume it has some sort of 32 bit compatibility mode, but we should still make it clear. I do (run WinXP 64) and yes: it executes win32 code flawlessly (and thanks for it, as only 2-3 software in 100 support win64 :P). I guess the best is just to avoid nominating win64 until there's an ACTUAL win64 package... ;-) (and it's not like mtn really *needs* the extra power...) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] building 0.38 on AIX
Stephen Leake [EMAIL PROTECTED] writes: Kelly F. Hickel [EMAIL PROTECTED] writes: The issue is that unix/tester-plaf.o gets included into libplatform.a, but needs symbols defined in tester.cc to actually link. The AIX linker is fairly pedantic about unresolved symbols, often to the point on insanity in my opinion. If I remove unix/tester-plat.o from the .a, then I can build the mtn binary. Files that are in a library but not the link should not cause unresolved symbol problems. What is pulling in tester-plaf.o without tester.cc? But I guess you are saying the AIX linker doesn't work this way; it tries to link the entire library whether it needs to or not? That seems more broken than pedantic. Another solution is to use the Gnu compiler and linker; would that be a problem? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Bug#455646: [Monotone-debian] Bug#455646: FTBFS with GCC 4.3: missing #includes
Zack Weinberg writes: 2) sqlite/vdbeaux.c:2212: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1746 GCC bug. Should be reproducible with the official Debian sqlite package. I do not have time to file a GCC bug report. There already is one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113 -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
RE: [Monotone-devel] building 0.38 on AIX
What is pulling in tester-plaf.o without tester.cc? But I guess you are saying the AIX linker doesn't work this way; it tries to link the entire library whether it needs to or not? That seems more broken than pedantic. Another solution is to use the Gnu compiler and linker; would that be a problem? -- -- Stephe This is with GCC/G++, using xlc has many more problems. Everything I've read suggests that using the gnu linker on AIX is, err, challenging ;- and not recommended... I'll give those changes a try later today. -Kelly ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
