Re: C++98/C++11 ABI compatibility for gcc-4.7
On 15/06/12 21:45, Gabriel Dos Reis wrote: On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote: IMO, at the /very least/, libstdc++ should go ahead and change std::string to be the new implementation. Once std::string is ABI-incompatible between the modes, there's basically no chance that anyone would think that linking things together from the two modes is a good thing to try, for more than a couple minutes. Agreed. While I realise it doesn't fix all problems (for example, with return values), is there any reason the C++11 ABI-incompatable types have not been put into a seperate inline namespace, so compiling fails at link-time rather than at run-time? Chris
a fork of gcc is sold for $26k?
Hello, Just found morpher dot com - it's based on GCC: Morpher is a compiler driven obfuscation solution for C/C++/ObjC/ObjC++. Being a compiler, our tool has much more structural information than any other tool that works directly with binary format. Therefore the abilities of Morpher's C++ source obfuscation are much higher than any binary cryptor can suggest. Our algorithm distorts the control flow graph in a controllable manner. We allow you to tweak the size and speed limitations to make application protection against reverse engineering most effective. One of many Morpher's areas of applicability is DRM market. Our software protection system allows obfuscating critical pieces of access control code flexibly and without severe performance losses. This effectively supplements your original copy protection scheme. They sell it for $26k (if you select all options and all platforms). Here http://stackoverflow.com/questions/4111808/c-c-compiler-generating-obfuscated-code one of its developers explains more about it: It is essentially a version of llvm-gcc with additional obfuscation passes - you're supposed to use Morpher as a drop-in replacement for gcc. Obfuscation passes include constant protection, cloning of basic blocks and functions, CFG arches meshing and others; they are described in the documentation section with examples of assembly. It looks it's developed by people from parts of ex-Soviet Union. Have anybody inspected it? Is GPL violated in this case or not (e.g. do they provide all patches they've made to gcc)? Thanks, Vlad
Re: a fork of gcc is sold for $26k?
On 16 June 2012 12:01, Arch hvv wrote: > Have anybody inspected it? Is GPL violated in this case or not (e.g. > do they provide all patches they've made to gcc)? If it's based on llvm-gcc then it only uses GCC as the front-end so there may be no reason to patch GCC.
Re: a fork of gcc is sold for $26k?
Hi, On Sat, 16 Jun 2012, Jonathan Wakely wrote: > On 16 June 2012 12:01, Arch hvv wrote: > > Have anybody inspected it? Is GPL violated in this case or not (e.g. > > do they provide all patches they've made to gcc)? > > If it's based on llvm-gcc then it only uses GCC as the front-end so > there may be no reason to patch GCC. In case they link-edit against GCC frontend (or backend, or just generally GPL protected) files and distribute the resulting binary they still must provide their own code linking against those under a GPL compatible license. I don't know of they do the former (or use llvm plugins), and if so, if they do the latter. The FSF might want to know, though. Ciao, Michael.
Re: a fork of gcc is sold for $26k?
Arch hvv writes: > Have anybody inspected it? Is GPL violated in this case or not (e.g. > do they provide all patches they've made to gcc)? If they provide the source code to anybody who purchases their package, then they are doing nothing wrong according to the GPL. I don't know whether they do or not, but in the absence of evidence I see no reason to assume they do not. In particular, there is no requirement that they make their source code available to the public at large. That said, discussions of GPL compliance are off-topic for this mailing list. If you want to pursue this, please write to licence-violat...@gnu.org, as described at http://www.gnu.org/licenses/gpl-violation.html . Thanks. Ian
Re: C++98/C++11 ABI compatibility for gcc-4.7
Hi, On Fri, 15 Jun 2012, Gabriel Dos Reis wrote: > On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote: > > > IMO, at the /very least/, libstdc++ should go ahead and change std::string > > to be the new implementation. Once std::string is ABI-incompatible between > > the modes, there's basically no chance that anyone would think that > > linking things together from the two modes is a good thing to try, for > > more than a couple minutes. > > Agreed. Careful. I find the (perhaps only perceived) enthusiasm for a soname bump most troublesome. Are you sure you have every ABI/API-incompatible change fully rolled out, implemented and tested already? As some c++ maintainers still claim that c++11 is considered experimental and incomplete I somehow doubt that. But if you do a soname change now you don't want to change it the next 10 years (better more). A soname change for a basic system library is a _major_ PITA and should be avoided even at large costs. In that light: do you have a plan of action of how to never change the soname again, at least on targets where that is reasonably possible with symversions? In fact, as we already use symversions also for libstdc++, a soname bump should be avoidable already now. Perhaps requiring some extensions to mangling, or giving the "new" classes a different assembler name for mangling purposes, or simply via the new namespace (I'm not sure that solves all issues). But even implementing special magic in the compiler usable by the library to control its ABI/API would be worthwhile if a soname bump can be avoided. Ciao, Michael.
gcc-4.7-20120616 is now available
Snapshot gcc-4.7-20120616 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120616/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 188697 You'll find: gcc-4.7-20120616.tar.bz2 Complete GCC MD5=2e1e23fd4becbb277a13087458389624 SHA1=98390a2319cb568621d1dc437bbd50ae547ae66a Diffs from 4.7-20120609 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: C++98/C++11 ABI compatibility for gcc-4.7
I have no plan for willful obstruction in solving this recurring and really annoying problem that trips up users again and again, under all kinds of reasons (both perceived or constructed.)
