Review your favorite Linux distribution.
Go Back > Blogs > rainbowsally
User Name


Rate this Entry

Computer Mad Science - UnCMake (to rip parts of cmake-d installations)

Posted 04-14-2012 at 07:34 PM by rainbowsally
Updated 08-06-2014 at 10:22 AM by rainbowsally (bug fix)

[See also UsR2usr for creating binary trees without committing to a full install until you can test the installation with this or any other package installer. ]

Bug Fix: Apr 24, 2012
[Corrected file names in the main executable. Ouch!]

uncmake-1.1.8 (system) installer/uninstaller

After installation try this.
uncmake -set ; ls /usr/bin/uncmake.*
uncmake -reset ; ls /usr/bin/uncmake.*
And watch the files change. uncmake.state is the flag file and uncmake.dir contains the path to uncmake.txt dump file.

uncmakefile is also and interesting app. Not as scary, but then it really needs uncmake to do much of anything really useful.

Here's the README.

This is a precompiled binary installer/uninstaller using make.

It installs 'uncmake' and 'uncmakefile' utilities for demystifying
cmake and other opaque make system builds.

To install requires root permissions. It installs all the files 
into /usr/bin, where we presume gcc, g++, and ld are also.  The
files TREE is an image of what gets installed minus the PREFIX
defined in the Makefile.

To install, as superuser type 'make install'.

To uninstall, as superuser type 'make uninstall'.


Uncmake -set and -reset switch between uncmake mode and normal mode
for dumping cmake commands to a file initially named uncmake.txt in
the folder where you execute the 'cmake' command.

It requires root permissions in order to switch states.

       This is a DANGEROUS but very useful application
               when used with a little caution


It will change the names of gcc, g++ and ld depending on the 
cmake.state (which is a file in /usr/bin that it creates) so that 
normal gcc, g++, and ld functions can be preempted by the uncmake 
utility when it is set.

Unless you update* while in cmake mode, the original files will be 
named /usr/bin/cmake.<name>.orig.  All of the files involved have
the "cmake." prefix.

* There is another potential problem besides updating while uncmake 
is -set as well.  See "NOTE" below.


What makes it dangerous is that uncmake may be in the wrong state 
if there's a power outage, or if you reboot while uncmake-ing.

It should be possible to 'uncmake -reset' after booting back up, but 
the output file will be corrupted by anthing that uses gcc, g++ or 
ld behind the scenes during the boot process.

uncmake doesn't depend on cmake.  It works with the files named above.

And things could get even worse if you upgrade your gcc, g++, or ld 
while uncmake-ing.  There's a good chance you'll have to reinstall 
them if you ever 'uncmake -reset' after this.  If it's already 
-reset when you upgrade there should be no problem since the files 
will all be restored to their original 'state' and cmake.state (the 
state flag file) will have been removed.

The best thing to do if this happens is to uninstall uncmake to 
remove junk files including 'uncmake.state' and reinstall it.  No 
guarantees.  That's untested but should probably work.

Gcc, g++, and ld are the only files affected.  You might want to back 
them up (whether they are symlinks or regular files) as an extra 
measure of safety.

NOTE that in addition to the above possible gotcha's some other 
utilities do the same thing to gcc, g++, and ld and these do not 
play well together.  For example, 'checkinstall' may cause problems 
with uncmake due to unsynchronized changing of these three critical 
files.  (This is unconfirmed but at one time, checkinstall backed up 
some pretty strange files shortly before a reinstall of gcc, g++, and 
ld became necessary.)

And while the scenarios described such as power outages and updating 
are fairly rare, this kind of issue with 'checkinstall' or other
similar apps could happen just as a matter of not knowing whose the 
boss in these situations at any time when both are working at the 
same time.

And one more issue to look out for is that ALL gcc, g++ and ld 
commands will get copied to the uncmake.txt file while uncmake 
is -set.  Even if another user executes commands that invoke these 
applications.  If it's a large file it could be quite time consuming 
to sift through and remove the unwanted portions of the dump.

Best used on a single user system.


What makes this useful is that we can see the exact commands cmake 
and most other make systems are running.

And with uncmakefile (included in this package) the output file can 
be translated into convenient sub-parcels of make commands that can 
be imported into a makefile in order to work with just one or a small 
handfull of the files you normally can't get at even if you could 
find them nevermind edit, debug, or test.

For example, did you know that kdesu is created by simply linking 
kwrapper.o with the output name kdesu?  That is not at all obvious 
but we can see this in an uncmake dump file.  Once we know this we 
can see that kwrapper takes the name from argv[0] and prefixes that 
name with 'lib' and does the call.  Pretty nifty trick.


There are some test<N>.in files in the uncmakefile-sources tarball if 
you want to see what it does.  

And there's a copy of the executable in the TREE folder you can copy 
for testing before committing to installation.

Uncmakefile does NOT require root permissions and is quite safe to play 
with.  :-)
Posted in Uncategorized
Views 711 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 10:55 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration