Re: GCC 4.1: Buildable on GHz machines only?
> Mike Stump <[EMAIL PROTECTED]>: > On Thursday, May 5, 2005, at 02:53 PM, Andi Vajda wrote: >> I wish the same were possible on Linux and Mac OS X but I have not >> been able to create a shared library that is statically linked >> against libgcj.a > Should just work, though, you don't want to link -static built objects > into a .dylib, you merely want to link in -fPIC built objects from a .a > into the dylib. Can you manage to do this with a small example? It's possible to do this. I've done it on linux. But if pieces of the .a appear in several .so files, and if these pieces comes from different versions, or different build configurations of the .a, there may be trouble. If you use -Bsymbolic when linking the .so files, you _may_ be able to make each .so file see the symbols from its own .a file. I wasn't able to make it do this. I was only able to use it to make an .so look inside itself for symbols, before looking at the globally available symbols. More here: http://thread.gmane.org/gmane.text.xml.expat.general/920
Re: Cygwin support
> Brian Dessent : [snip! Access from plugins to every aspect of the compiler] > ... This means you'd have to move essentially everything into this > mega-DLL, leaving cc1 and friends as merely stubs that set a flag and > then call into the DLL never to return, since anything left in cc1 > would not be accessible from the plugin. FWIW this is not an uncommon situation for Win32 executables, especially for multiplatform application and/or applications ported from unix.
Re: Using C++ in GCC is OK
> Mark Mitchell : > I think virtual functions are on the edge; quite useful, but do result > in the compiler adding a pointer to data objects and in uninlinable > indirect calls at run-time. Therefore, I would avoid them in the > initial subset of C++ used in GCC. Umm...? Virtual functions are _the_ core C++ feature for creating OO frameworks. Allowing C++ but avoiding virtual functions seems odd to me.
Re: Using C++ in GCC is OK
> Larry Evans : > claims that switch statements are faster than virtual function calls. That's not really interesting, is it? The overhead and downsides of virtual functions are well known. The upside is the possibility to use polymorphism to make frameworks. All kinds of pluggable frameworks. And as polymorphism goes, virtual functions are pretty cheap.
Re: New file extension
> Martin Jambor : > Well, IIRC mostly worries about history. SVN claims to be able to > track history of renamed files but I use the git mirror now and I > wonder what the history would show there. I would consider it very > unfortunate if 'git blame' did not show the .c era history of the > renamed files. But maybe it would just work. It depends on how the rename if done. If a file is added that has the exact same SHA1 hash as a file with a different path, then git assumes that the new file is a copy of the other file, and blame and the log history can be made to follow the history beyond the copy. Actually "git blame" always follow the history across renames, and "git log" needs the "--follow" option, or a config setting, to do so. I have no idea what git-svn (or whatever) will do when it comes to an svn rename, but it would make sense if it replicated it by a commit that does a git rm of the file in the old location, and a git add of the file in the new location. If the svn rename also changes the renamed file, then things get trickier... git-svn would have to split that commit into two.
