A Recognition

I just won myself a recognition at the office in this month’s “Star of the month” competition. It was for my one month effort to deploy, and stabilize ccache in our considerably large software project that I was awarded this. This was done keeping the build time, and the cost of ElectricAccelerator’s license in mind. While I partially won by decreasing the build time by nearly 40% on an average, and meeting the first expectation, I failed to save the cost, as the pressure on resource crunch was huge, and we had to purchase more licenses.

We are aiming at our next promising thing, Tup, a blazing fast, and incredibly accurate, OpenSource build tool. While its adoption on the OpenSource world looks very modest, it is by far, the best OpenSource build tool available as of now, from what I know. I’m hopeful that this should help us accomplish both the targets, of increasing the developer productivity by not wasting lot of time waiting during building stuff, and saving the organization some cost.

I’m not going to quit until this Tup build system is rolled out!

And When Things Go Wrong!

We had a terrifying issue last Friday. Due to a mistake my peers did, nearly a few hundred users lost their access to Subversion, and reinstating their access was pretty much a nightmare as this sort of thing never happened in the past. I’d my share of suggestions on how this can be prevented from happening again, and etc, and things became stable only this morning!

Today evening, we had a retrospective session held by our manager, and he and the senior folks had some suggestions for the peers who are beginners.

As I kept hearing the suggestions, I recalled my last job and the mistakes I made. Lucky enough, I had one friend who stood by me often times and helped me correct things. What he never told me persistently was(or at least, I can’t recall being told) “Hey, this is how you can improve, and never repeat a mistake.” I was a lone wolf who wasn’t having that retrospective mindset either. If I had gotten a chance to work in a team like the one I’m in now, right from beginning, probably, I’d have been much better than what I’m now. And in that sense, beginners in my team have got better opportunities.

My point about these mistakes is

  • When in doubt, we should ask.
  • Think before we hit enter. In IT industry things are one click away. Whether it is granting access, or disabling access, or creating a Cloud host or just clicking on something. It is in one click that a worm can spread, a bunch of machines can go down, or a website is shut down or confuse the whole Internet world that googles around.
  • Feedback or criticism should be taken positively.
  • Whether the issue is created by our team, or assigned to our team; if we are the ones to fix it, fix it as per the priority.
  • A checklist has to be there if the task is big enough, and plan not to release things on Friday. Not because we will be disturbed while on weekend outing, but, things will be held up over the weekend as not all the stakeholders may be available over weekend.
  • Accept the mistakes.

That said, I broke something early last week, even though I took utmost caution. And that called for a checklist. I believe I’m no longer the guy who never had a retrospective mindset, but someone who learns from his mistakes, and strives to do things cleanly.

Nobody is perfect. The more preventive we are, the better things turn out. Isn’t it?

Uh, by the way, “To me, you are perfect” is just a Love Quote from Love Actually. You know, just in case perfectness reminded you of that! 😉

distcc for Distributed Compilation – gotchas!

After getting our builds run with gnu make in parallel, we spent some time evaluating “distcc” for distributed compilation. I had some hiccups and learnings. I’m hopeful that the following shall be useful and handy if you are just starting to use distcc.

  • In our build environment, the directory where compiler is stored keeps changing as we have very frequent SDK updates. The compiler is accessed via soft link, and only this soft link is moved to the new path when we have SDK updates. So, we do not have a fixed absolute location to compiler that can be used by the distcc wrapper, and I’d to make sure that the distcc wrappers are written on-fly with absolute path to compiler before the build starts. So, what I did was, while the CC/C++ Compiler path was initialized, I ensured that the wrappers are written into the user home directory/a directory(DISTCC_WRAP_STORE) that is available both on build machine, and the distcc servers.

CC := $(PUMP) $(DISTCC) $(DISTCC_WRAP_STORE)/x86_64-unknown-linux-gnu-gcc -m32

$(shell echo $$(readlink -f $(LINUX_I686_GCC_BIN_DIR)/x86_64-unknown-linux-gnu-gcc) \""\$$@"\" >> $(DISTCC_WRAP_STORE)/x86_64-unknown-linux-gnu-gcc )
$(shell chmod a+x $(DISTCC_WRAP_STORE)/x86_64-unknown-linux-gnu-gcc)

  • disctcc wrappers must be executable files, and they seem to work only when they have the absolute path to the compiler in them! Otherwise, the errors you see are quite weird, and they give no clue about the missing execute permissions or the relative path.
  • If you are using .d files generated by GCC compilers, then the .d files may end up created in current directory from where compilation starts, while you might be expecting them in the object directory This problem can only occur if you’re using gcc 3.0 or later, have the source and object files in different directories or under different names, and you are using -MD or -MMD but not -MF. Even with -MF in place, the first line in the .d file, which is the path to the object file, may not really contain the object.o, instead it will be source.o if source, and object files have different name! ie. you are compiling errorHandler.c to errorHandlerM.o and in this case, you gotta make sure you correct the .d file after it is generated.

I will add more findings, if I come across any. We have some troubles with PUMP mode right now, hopefully, we will get through them.

CSS Popup Box With Background Disabled

It is my curiosity to right mouse click on a web page, and click “Inspect” that comes with Firebug every time I find a web page catchy. I’ve been trying to have a CSS pop up box that forces some type of confirmation, and while the question asked in the pop up isn’t answered, I wanted to have the parent background disabled (ie. no anchor links from the parent should be active/clickable)

I’d some options in mind, but I was unhappy with them as they seem to be inelegant. So, I went on to analyze how it is done on some of the websites. For instance, on Facebook here is what they seem to be doing as of this moment, the way I understand.

Say you wrote something in the “Update Status”, but clicked on something else. You are likely to see a pop up that asks whether you are sure about navigating away from the page.


The pop up that you see will have the following CSS rules.

.generic_dialog_modal, .generic_dialog_fixed_overflow {
    background-color: rgba(252, 252, 252, 0.9);
    height: 100%;
    z-index: 400;
.generic_dialog {
    left: 0;
    outline: medium none;
    overflow: visible;
    position: fixed;
    top: 0;
    width: 100%;

As z-index of this div that encloses the pop up div is 400 (must be the highest among all the elements), height being 100%, top being 0, position being fixed, the popup occupies the entire page on top of the any other element on the page.

If you want to find a way to click the links/images on the apparently disabled background, then just go on reducing the z-index using firebug, and you will notice that the right chat/update dock box+graph search portion opens up first, then the rest of the page become visible and the links becomes active, and dialogue box disappears when z-index is less than 0.

So, this seems to be one elegant and simple way to have a CSS pop up, with disabled/diminished background. 🙂

I hope this post is helpful.

Change in the linker behavior(binutils2.2?)

I’m currently handling the task of migrating/trying our builds on RedHat6.x So far our builds are run on RedHat 5.3/5.5 and given that we are running on relatively older version of RedHat, we are planning on migrating.

One of the issues I observed was with the way version 2.2 of gnu ld works. I’d built binutils 2.2 on redhat 6.1 machine and it looks like the way dynamic linking works has changed slightly. The following was the error I got. I don’t see this on binutils 2.1.x

/usr/bin/ld: note: 'some_reference' is defined in DSO some.so so try adding it to the linker command line

I read about the possible work-around, rather fix I’d say, at Fedora Wiki page http://fedoraproject.org/wiki/UnderstandingDSOLinkChange , and it worked just fine in our case.

The bottomline is, while generating binary/.so out of objects/shared objects, you should make sure that any dynamic linked library that resolves the references to the symbols in these objects/shared objects must also be linked dynamically even while generating binary/.so i.e no indirect linking anymore..

If my explanation doesn’t make sense, read through the wiki link given above, and you will be out of confusion.