M$ Vestigials: nmake and CMD.EXE

I was trying to integrate my Linux PPC build with TFS build and the only way I found this possible was via a "nmake" VS project. This is just contorted: a VS 2010 project wrapping a nmake Makefile is promoted to "build" status.

All this fuss just to map a Samba share, SSH into the Linux build machine and perform the build (the denx cross-compiler we use is only hosted on Linux).

The nmake is a pale and withered imitation of the one true make, the GNU make.

And I am not saying it for lack of trying: nmake does not pick up environment variables correctly and it certainly does not allow me to say

TIMESTAMP = $(shell unixdate '+%%Y-%%m-%%d_%%H.%%M.%%S')

Also it does not follow the respected idiom CC ?= gcc (i.e. Set the CC variable to "gcc" if it wasn't set alteady in this Makefile or the environment.)

This may seem obscure but if one wants to get TFS to get a snapshot onto uniquely named directory onto a Linux samba share then one is out of luck.

Which brings me to the need to have a CMD batch file to handle all this. The backticks implementation in CMD is heinous:

for /F "usebackq" %%a IN \
    (`"unixdate +%%Y-%%m-%%d_%%H.%%M.%%S"`) \
    do @set TIMESTAMP=%%a

Yes, these are the wrong way to do stuff on a Win32 machine but you do what you have to do to get the job done.

-ulianov

When make(1) Starts Spinning in Circles

I have this Linux project where the "depend" Makefile target reads:

${DEPDIR}/%.d:  %.cpp
 @echo "Determining dependencies for $<"
 @${CXX} ${CPPFLAGS} -E -MM $< | \
   sed -e 's~\($*\)\.o[ :]*~\1.o $@ : ~g' > $@

In one instance this snippet would start to run in an infinite loop.

On a closer look it turned out that the build machine I was trying to make this the system clock was waaay behind the `real' time and there was nope in h*ll to get it sync'ed as the corporate firewall blocks the S/NTP.

The files were checked out out of TFS via Samba which somehow preserves the time stamp of the client Win32 machine (whose clock was right).

The clock being behind it means that all builds artefacts were indeed older than the files that came out of revision control, thus the infinite loop.

The solution is rather simple (as this is build machine, not a dev machine):

# The time on the Linux build machine may drift
# and be behind the time of the TFS agent. Yet when
# files are deposited on the Samba share their
# time stamps come from the agent and that can
# be "newer" than any file we produce locally
# on the Linux machine thus triggering an IFINITE loop.
#
# We time stamp all files with the (same) local time
# stamp to avoid this.
CO_TIME=$(date '+%Y%m%d%H%M'); export CO_TIME
find -type f -exec touch -t $CO_TIME {} \;
unset CO_TIME

What's frustrating is that I had this problem 4 years ago when I did not have this blog to remind myself of build oddities.

Also during the same exercise I learned that the Win32 DEL command does not cope well with symlinks on the Samba share so it needs a small assisst at the end of the build:

find -type l -delete

-ulianov

Speeding up XFree86 Startup on a x86 Target

I have an embedded motherboard with the ?i945G? graphics chipset. XF86 4.6.0 would take 11 seconds of blank screen to start up which is unacceptable for an embedded applicance [the user might think that the system went belly-up].

While playing with vesafb I learned that if I start Linux in graphics mode vga=0x314 (which also enabled me to claim half of the boot screen with the company logo) the start up time of the XF86 (same server) is cut to only 1.5 sec.

Prior to this I tried Xvfb which starts instantaneously but it's horrendously slow.

-ulianov

P.S. Bolting the logo into the kernel using a 224 colour ppm ASCII bitmap is gross.

Circumventing a Corporate Firewall

Having work in the NA corporate world for a while now I can list a few ways of circumventing firewalls and freely communicating with the outside world.

Keep in mind that corporations have edge firewalls and restrictive firewalls on the users' computers which in most cases run Windows XP.

Here are a few ways I got it working for edge firewalls:
1. running OpenVPN over UDP/33400 [apparently this port and and a few after are used by tracert];
2. running OpenVPN over TCP/21: this is used for FTP and some corporations allow direct FTP connections;
3. running OpenVPN over TCP/1194, which comes as no surprise at this is the IANA OpenVPN port;
4. tunnel over HTTPS with CONNECT but this is short-lived.

Sometimes when one sells a device which needs to be controlled over Ethernet then it is next-to-impossible drive it for people have those pesky local firewalls.

Some esoteric ways to confound a local firewall would be:
1. use a Windows named pipe to talk to a Samba program that is the server for the named pipe;
2. use payloads for icmp-request and icmp-response in fact implementing a UDP/ICMP; some firewalls block incoming ICMP;
3. make the device respond with icmp-destination-unreachable (with payload) which are never blocked else all the IP stack is thrashed.
4. use UPnP to exchange data.

-ulianov