Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
Daniel Berlin wrote: You can't mix svn and svk commits against the same repo. It confuses svk (not svn). You can use svk readonly, of course. Actually, that's not quite right. While svk's depot must only be used by svk, the usual usage is to mirror a regular subversion repository with svk into a svk depot, then work with it from there using svk. Any changes in the svn repository are pulled in with svk sync, and any changes to the mirrored copy are applied to the backing subversion repository. Except that http://svk.elixus.org/?SVKFAQ says "Given an svk repository, do you have to use it via svk, or can you use svn programs to access it? Short answer: svn programs that only read the repository are working fine; those who actually write in the repository would bypass svk and make it fail. " Vital difference: This will work: svk mirror svn://wherever //svnrepo/mirror # do svk things with //svnrepo/mirror # do svn things with svn://wherever This won't work: svk mirror svn://wherever //svnrepo/mirror # do svk things with //svnrepo/mirror # do svn things wioth file://$HOME/.svk/local/svnrepo/mirror signature.asc Description: OpenPGP digital signature
Re: Details for svn test repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joern RENNECKE wrote: | Daniel Berlin wrote: | |> |> And towards this end,i'm working on making blame a lot faster |> |> | | Will this also cover annotate using an -r option to go past the last | reformatting | delta? | |> Other than that, what operations are people still worried about the |> slowness of? |> |> | | Because svn keeps an extra pristine copy for checkouts, I'll have to use | svn export for | automatic regression tests. With cvs, the overhead of the cvs | information is small, | so I could use checkouts, and when I wanted to work on / test some | patches with a | baseline known to build and to have a specific set of regressions, I | just copied over the | checked out tree and started working on it. With svn, I'll have to do a | fresh checkout of | the files/directories I'll be working on. The book mentions that there | is an intent to make | the extra pristine copy optional, but AFAICT this isn't something that | is available now. Can't you use a single checkout with svn switch, or patch it and svn revert when done? Alternately, use svk, and create local branches for whatever changes you want to save. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCDOe3+hz2VlChukwRAl8hAKCJdAQ5XJmgVuSiH2vx1q9kvGf7IQCeMKhO C7C9WYy8IKz4lwfH++MRdvQ= =VU95 -END PGP SIGNATURE-
Re: Details for svn test repository
Daniel Berlin wrote: On Fri, 2005-02-11 at 17:13 +, Joern RENNECKE wrote: Joseph S. Myers wrote: You mean the revision number of the whole checked out tree, which the "svnversion" utility will tell you in any checked out svn tree (including whether the tree is modified or mixed version). Given such a number, if you don't intend to do svn operations on that tree afterwards you can remove the .svn directories and reconstruct the checked out tree using the version number later. Is there an svn command to do that without doing a new checkout from the repository? You mean tell you what the current version of the repo is? svnlook can do it, but it requires direct access to the repo. I could always make something that just prints out svnlook youngest to a socket and closes the connection (so you could netcat it or whatever), if that is what you need. Alternately, parse the output of svn ls -v on the repository root, and select the highest revision number cited. This requries no changes on the server. signature.asc Description: OpenPGP digital signature
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
Daniel Berlin wrote: On Fri, 2005-02-11 at 12:08 -0500, Daniel Jacobowitz wrote: On Fri, Feb 11, 2005 at 12:00:26PM -0500, Daniel Berlin wrote: Because if it's a show stopper, then so will be arch, monotone, or any of our other replacements (they all either store the entire repo on your disk, or have stuff in the working copy), and we will be stuck with cvs until everyone is happy to use up double/whatever disk. Actually, having one copy of the entire repository might be cheaper than having several dozen double checkouts. Yes, at some point the double space outruns the cost of the entire repo. For gcc, the cost of the entire repo is 4.4 gig right now. For your case, it might be cheaper to rsync the repo (unlike cvs, for each extra global revision to download, it's going to be 1 new file, and the old files won't be different. So it's going to be a *very fast* rsync), and export directly from that. Since I think this is a very important point, I'm going to contribute a couple of supporting statistics... The CVS repository is about 2.6GB. 3200989 cvsfiles oh, wait, that includes wwwdocs and whatnot, sorry. A complete CVS checkout is 260MB, or about 10% of the repository. If you've just got the one checkout, the checkouts win. I've got a dozen right now; from what I've been hearing, svk would be the biggest win for me. You can't mix svn and svk commits against the same repo. It confuses svk (not svn). You can use svk readonly, of course. Actually, that's not quite right. While svk's depot must only be used by svk, the usual usage is to mirror a regular subversion repository with svk into a svk depot, then work with it from there using svk. Any changes in the svn repository are pulled in with svk sync, and any changes to the mirrored copy are applied to the backing subversion repository. For more information: http://svk.elixus.org/?SVKUsage signature.asc Description: OpenPGP digital signature
segmentation fault with fclose
Hi,
I'm trying to close a file using fclose, but the following program seg-faults:
#include
int main(void)
{
FILE* fp = fopen("unfounded.txt", "r");
if(fp == NULL)
fclose(fp);
return 0;
}
The file I'm trying to open doesn't exist in the directory, so fp is
indeed NULL. So it's just fclose(NULL).
Is fclose(NULL) legal according to the C standard ? As an end-user I
expect fclose(fp) to close the file (if it is already open) or just do
nothing (if it is not open). So the seg fault -- is this a compiler
bug ?
PS: I hope this is the right place to ask this question.
-- Satish.BD
Snapshot tarballs for 4.7-20110528
Hi, All these days there used to be different tarballs like gcc-core-*.tar.bz2, gcc-fortran-*.tar.bz2, etc. in the snapshot directory ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-4.7. But now I see only one combined tarball (starting with 4.7-20110528). I liked separate tarballs on a per-language basis (g++, fortran, etc.). Could somebody point me to the reasons for this change ? I couldn't find any announcement regarding this change either. Thanks & Regards, -- Satish.BD
std::count leaked outside namespace std?
Hi,
Here's a simple program:
#include
#include
int main()
{
std::vector vec;
count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
}
The above compiles successfully, but I think it shouldn't. I expect a
message like "error: `count` not declared in scope" because I meant to
say std::count. Isn't this a bug, or am I missing something?
Behaviour is reproducible with both GCC 4.7 and 4.8.
PS: I'm not subscribed to mailing list, please keep me in cc.
Thanks,
Satish
Re: std::count leaked outside namespace std?
Thanks Paolo, ADL is news to me. On 24 April 2013 01:43, Paolo Carlini wrote: > You are: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup > > Paolo. >
GCC 4.7.2: Mudflap linker errors
Hi,
The following piece of code, gives "undefined references" to
__real_malloc, __real_free, etc.:
// references.cc
#include
void func(int& x) {
x = 0;
}
int main() {
int* p = NULL;
func(*p);
}
Compiled with:
g++ -fmudflap references.cc -lmudflap
/lib64/libmudflap.a(mf-runtime.o): In function `__mfu_check':
../libmudflap/mf-runtime.c:912: undefined reference to `__real_malloc'
../libmudflap/mf-runtime.c:1028: undefined reference to `__real_free'
../lib64/libmudflap.a(mf-runtime.o): In function `__mf_insert_new_object':
../libmudflap/mf-runtime.c:1074: undefined reference to `__real_calloc'
../lib64/libmudflap.a(mf-runtime.o): In function `__mfu_unregister':
../libmudflap/mf-runtime.c:1430: undefined reference to `__real_free'
../libmudflap/mf-runtime.c:1433: undefined reference to `__real_free'
etc.
My system is Debain 6.0, here is how gcc-4.7.2 was configured:
Target: x86_64-unknown-linux-gnu
Configured with: ../configure
--prefix=/home/bdsatish/foss/installed/gcc --enable-languages=c,c++
--disable-multilib --disable-multiarch --enable-checking=runtime
--enable-libmudflap --enable-libgomp --disable-bootstrap
--enable-static --disable-shared --disable-decimal-float
--with-system-zlib --disable-libitm
--disable-build-poststage1-with-cxx --disable-build-with-cxx
--without-cloog --without-ppl --disable-nls --enable-threads
--enable-__cxa_atexit
Thread model: posix
gcc version 4.7.2 (GCC)
I think this is a bug or regression, I asked in freenode#gcc and hence
reporting here instead of gcc-help.
Thanks for the understanding.
Regards,
Satish
Re: GCC 4.7.2: Mudflap linker errors
Hi, Here is the output of (gcc -v): Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/user/installed/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/user/installed/gcc --enable-languages=c,c++ --disable-multilib --disable-multiarch --enable-checking=runtime --enable-libmudflap --enable-libgomp --disable-bootstrap --enable-static --disable-shared --disable-decimal-float --with-system-zlib --disable-libitm --disable-build-poststage1-with-cxx --disable-build-with-cxx --without-cloog --without-ppl --disable-nls --enable-threads --enable-__cxa_atexit --with-gmp=/home/bdsatish/foss/installed/gmp --with-mpfr=/home/bdsatish/foss/installed/mpfr --with-mpc=/home/bdsatish/foss/installed/mpc Thread model: posix gcc version 4.7.2 (GCC) Thanks & Regards, Satish On 22 September 2012 04:33, Frank Ch. Eigler wrote: > bd satish writes: > >> [...] >> The following piece of code, gives "undefined references" to >> __real_malloc, __real_free, etc.: >> Compiled with: >> g++ -fmudflap references.cc -lmudflap >> >> /lib64/libmudflap.a(mf-runtime.o): In function `__mfu_check': >> ../libmudflap/mf-runtime.c:912: undefined reference to `__real_malloc' >> [...] > > According to libmudflap/mf-impl.h, since you're using ordinary > archives rather than shared libraries (-fPIC) these __real_FOO > functions are expected to be provided by the linker: > >(1) The static method involves a list of -wrap=foo flags being passed to >the linker, which then links references to "foo" to the symbol >"__wrap_foo", and links references to "__real_foo" to the symbol "foo". >When compiled without -DPIC, libmudflap.a contains such __wrap_foo >functions which delegate to __real_foo functions in libc to get their >work done. > > So, something appears wrong with this wrapping mechanism in your case. > Can you rerun g++ with -v to see how the linker is invoked? Perhaps > there is something missing for the C++ static-linking case. > > > - FChE
Re: GCC 4.7.2: Mudflap linker errors
.a(mf-runtime.o): In function `__mf_insert_new_object': /home/user/foss/gcc-4.7.2/build/x86_64-unknown-linux-gnu/libmudflap/../../../libmudflap/mf-runtime.c:1074: undefined reference to `__real_calloc' /home/user/foss/installed/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib64/libmudflap.a(mf-runtime.o): In function `__mfu_unregister': /home/user/foss/gcc-4.7.2/build/x86_64-unknown-linux-gnu/libmudflap/../../../libmudflap/mf-runtime.c:1430: undefined reference to `__real_free' /home/user/foss/gcc-4.7.2/build/x86_64-unknown-linux-gnu/libmudflap/../../../libmudflap/mf-runtime.c:1433: undefined reference to `__real_free' /home/user/foss/gcc-4.7.2/build/x86_64-unknown-linux-gnu/libmudflap/../../../libmudflap/mf-runtime.c:1436: undefined reference to `__real_free' PS: Please keep me in CC, I'm not subscribed to the list. Thanks & Regards, Satish On 22 September 2012 08:11, bd satish wrote: > Hi, > > Here is the output of (gcc -v): > Using built-in specs. > COLLECT_GCC=g++ > COLLECT_LTO_WRAPPER=/home/user/installed/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper > Target: x86_64-unknown-linux-gnu > Configured with: ../configure --prefix=/home/user/installed/gcc > --enable-languages=c,c++ --disable-multilib --disable-multiarch > --enable-checking=runtime --enable-libmudflap --enable-libgomp > --disable-bootstrap --enable-static --disable-shared > --disable-decimal-float --with-system-zlib --disable-libitm > --disable-build-poststage1-with-cxx --disable-build-with-cxx > --without-cloog --without-ppl --disable-nls --enable-threads > --enable-__cxa_atexit --with-gmp=/home/bdsatish/foss/installed/gmp > --with-mpfr=/home/bdsatish/foss/installed/mpfr > --with-mpc=/home/bdsatish/foss/installed/mpc > Thread model: posix > gcc version 4.7.2 (GCC) > > Thanks & Regards, > Satish > > On 22 September 2012 04:33, Frank Ch. Eigler wrote: >> bd satish writes: >> >>> [...] >>> The following piece of code, gives "undefined references" to >>> __real_malloc, __real_free, etc.: >>> Compiled with: >>> g++ -fmudflap references.cc -lmudflap >>> >>> /lib64/libmudflap.a(mf-runtime.o): In function `__mfu_check': >>> ../libmudflap/mf-runtime.c:912: undefined reference to `__real_malloc' >>> [...] >> >> According to libmudflap/mf-impl.h, since you're using ordinary >> archives rather than shared libraries (-fPIC) these __real_FOO >> functions are expected to be provided by the linker: >> >>(1) The static method involves a list of -wrap=foo flags being passed to >>the linker, which then links references to "foo" to the symbol >>"__wrap_foo", and links references to "__real_foo" to the symbol "foo". >>When compiled without -DPIC, libmudflap.a contains such __wrap_foo >>functions which delegate to __real_foo functions in libc to get their >>work done. >> >> So, something appears wrong with this wrapping mechanism in your case. >> Can you rerun g++ with -v to see how the linker is invoked? Perhaps >> there is something missing for the C++ static-linking case. >> >> >> - FChE
Re: GCC 4.7.2: Mudflap linker errors
Hi Matthias, The error is from GCC which I built on my own (as mentioned in my first post), not installed from a package manager. It all works ok with the system compiler though (Debian 6.0 has gcc 4.4.5). Thanks & Regards, Satish On 22 September 2012 14:50, Matthias Klose wrote: > On 21.09.2012 23:08, bd satish wrote: >> g++ -fmudflap references.cc -lmudflap > > you have to install mudflap to use it (it is suggested by the gcc-4.7 > package). > sudo apt-get install libmudflap0-4.7-dev >
