AU compilation Issues - part II

AU compilation for TS 1.3 PL10 solved : 

Even though DRX499 was running only a 32 bit distro, au compilation was failing even after I installed the latest glibc.   The failure was occurring with the linker binary i.e. ld. The Bruker's stock 'ld' did not work for some reason.  The kludge I found in the web is one of two types :

• Edit the /usr/lib/libc.so.  Change the following phrase : GROUP ( /lib/libc.so.6  /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) to  GROUP ( /lib/libc.so.6  /usr/lib/libc_nonshared.a  ). I could confirm indeed that this works.  People out there add a warning to change the phrase back to the original after you are done, since some other application will need this original configuration of libc.so
• Alternatively, link the /usr/bin/ld  script to the appropriate location within your application.  In my case it is :  $TSHOME/gnu/i686-pc-linux-gnu/bin.  This too does the job. 

But it turns out that Bruker itself provides an elegant alternative to this without messing with the system or the application's distribution.   Here it is :

• Edit the file $TSHOME/exp/stan/nmr/au/makeau
• 
  
• Uncomment the # $opt_native = 1; 

This perl script, which is responsible for handling the 'au' program compilation, then sources  'gcc' as well as the linker scripts from the system's own distro rather than from the $TSHOME/gnu tree.  I could confirm that the compilation proceeds without any issues now.

Topspin Display issues and Fedora - in General

I am revisiting a topic that has been already touched upon, but since this seems to be a recurring theme, I am summarizing the remedy to these problems in this post.
For example, look at this xwinplot related post earlier.

The common problem with xwinplot, nmrsim or similar is the fact that, missing display libraries make the said program die quietly.  This makes it impossible either to display a pulse program or start up the plot editor and do your thing.   I had referred to this Bruker bug post earlier, which captures the content of the problem.   The simple take home message that will help us solve this display related problem is this.  In a shell window, run the following (I am using the example of nmrsim here):

/opt/topspin/topspin -e ldd /opt/topspin/prog/mod/nmrsim.mod

You can substitute plot in place of nmrsim.mod if you are trying to troubleshoot the failure of plot module.

Now,  you get a listing of all the shared object libraries that are required and found in your distro. example : libXt.so.6 => /usr/lib/libXt.so.6

If one or more libraries are missing, on the other hand, you see something like this:

libXmu.so.6 => not found

libXpm.so.4 => not found

Your job now is to simply install these missing libraries. In case of Fedora you can simply search for libXpm or libXmu using yum and install them.  Tip:  Just install the i386 or i686.  For Topspin, you don't need the x86_64 libraries any way.  

Now fire up the respective program withing TS viz. nmrsim or plot and confirm that it works.  It did, for me.    You can iterate this procedure for any other modules with which you might have trouble later on.  The message is the same.  You are missing some important shared libraries.  Go find them !

Peaceful co-Xistence : XWIN and TS on the same machine

since I still have an incentive to keep the XWINNMR chugging along (since I am still busy putting together the XWIN -> TS transition plan) but on the other hand I do despiiiise the unpatched RHL8.2 (!!) sucking up resources with runaway processes, I wanted to experiment with running XWINNMR on the shiny RHEL 5.4.

I have been making progress, so far. Here is a useful summary of what matters, for future reference :

• Since XWINNMR and the associated installation suite is matched evenly with the the RedHat 8.2 in antiquity,  there are non-existent locations in RHEL5 such as /usr/lib/X11 that need to be made up.   Refer to my post on how Xwinplot , which also belongs to the same generation as the Xwinnmr itself, was made to work in a RHEL5.4 platform to get a feel for what I am talking about.
• The Xwinnmr suite has the installation script called startme and this looks for xterm in /usr/X11/bin.  If it is non-existent, it quits. So do this :
• ln -sf /usr/bin/xterm /usr/X11/bin/xterm
• If need be, create the directory tree X11/bin under /usr,before creating the link as above.
• Since running the startme script from CDROM leads to file permission issues (I don't know why), I copied the startme script and two other directories that were on the CDROM to /tmp.    It took a while for me to copy all the contents of the CDROM to /tmp and so there is an additional overhead. But once this was done, the SWIM install interface launched without issues.   When run from CDROM, somehow X complains about   DISPLAY.
  
• OS type:  For some reason if the script compalins about non-compatibility of the OS, you can silence the same by doing so:
• sh ./startme --no-os-check
• There are several other switches that may be useful on special occassions.  To list them all, do this :
• sh startme --help-work-around
• If you have problem bringing up the swim gui, do this :
• sh startme -d localhost:0.0

The installation proceeded smoothly after this.  Since I already have installed Topspin on this host, I moved the original /usr/diskless to /usr/diskless.TS to avoid the conflict.  Similarly I moved the /usr/local/flexlm tree to a different name to avoid any clashes.

The installation part proceeded quite easily. The problem I am tackling at this point is to make the 24 and 8 bit overlay mode work fine with X11 so that Xwinnmr can render the colors correctly.  I will post  an update on this topic once that issue is sorted out.

Win over the XWINPLOT...

Since XWINPLOT is still a plot editor that belongs to the 'archaea' branch of computer programs, time and again you can end up with the frustration of making peace between the old and the new. One such instance arose when I upgraded the RHEL v4 to RHELv5.4 on DRX499, which runs Topspin 1.3 PL8.

Fortunately, I did not throw away the v4 distro and that saved me a LOT of trouble, as you will see below.

First, when I start the plot command,  the status bar says that plot progam is starting but it silently commits suicide, without leaving a discernible trace. When I captured the hist output (there is no savelogs command here; another of the quirks of TS1.3) and sent it to HQ, Mike Engelhardt forwarded me this Bruker Knowledge base link and said that my problem is similar to the one addressed :

http://www.bruker-biospin.com/shell/bkb/show_bug.cgi?id=8702

Basically this item highlights the fact that how xwinplot dies quietly if some of the needed shared libraries are not found.  In my case, there were two :

libdps.so.1

libdpstk.so.1

This is where the old distro. came in handy. When I located these files in RHELv4 distro., they were sitting under /usr/X11R6/lib.  The lib directory was completely absent in the case of RHELV5.4.

Solution :

• I copied over the entire directory /usr/X11R6/lib from v4 to the v5.4 distro. Even though the above said libraries were now available, the plot program could not still see these. 
• Therefore I created a soft link from /usr/X11R6/iib/ for the above two files into /usr/lib/ with identical names.  This solved the problem of plot dying prematurely.  It turns out that, with RHELv5.4 distro, /usr/lib is where the plot program is looking for the libraries. 
• By the way, the command I used to list out the libraries that were missing is given in the Knowledge Base article : 

topspin -e ldd /opt/topspin/prog/mod/xwinplot.mod

Now plot is working properly and I am also able to print the spectrum, as before.

Before I stumbled onto using the old distro to rummage the files, I tried some web search for the above two library files and the process was ugly, to put it mildly. So, it is a good thing to keep the backward compatible stuff around for a bit, until we iron out all the problems in the migrated system.

tricks and treats..

Here are a few 'postit' type notes that will come in handy. I will keep adding to this list whenever I catch a fish or two to add :

NMRSim installation

• When you install TS1.3 or TS2.1 in a EL 5 or Fedora 10 like environment, you might get a complaint from NMRSim that it is not able to find : /usr/lib/X11/app-defaults.  Simply do this :
• ln -sf /usr/share/X11/app-defaults /usr/lib/X11/app-defaults
• Now reinstall NMRSim and the error will evaporate away.  

curdir and write permisssion :

• Whenever you install a newer version of TS or XWIN, it often happens that the write permissions for the tree is changed en masse to a given user like nmrsu. It important that many of the directories need to have write access for all users for normal operation, on one hand, but a global write is a bad choice from security viewpoint, on the other.  You can create a separate group for all the NMR users involved and chgrp the tree to that special group and provide write permission for the tree and this is an acceptable solution. 
• But, there is one directory, i.e. $TSHOME/prog/curdir/$nmruser, for which this does not work i.e. the respective nmruser needs to be the owner of this branch of the tree.  So, you must remember to chown the curdir/$nmruser to nmruser:nmruser for proper fucntioning of TS for that user's login. Also, don't forget the '-R' switch while you do this.

smoking out the port on which the CPRserver is running - the easy way..

• Let me add that this tip is relevant when you are not  sitting at 'the spectrometer' console. If you are, simply enter hist on command line and find out the port number from there. But, if your spectrometer is in planet Mars and if you are at your desk, travelling back and fro is a bit trying.  That is where this tip becomes quite useful.
• First of,  ssh into the remote host.
• Then,
• cd /opt/topspin/prog/curdir/current TS user
• cat CPR.ref
• The text output of CPR.ref will show a string such as :  corbaloc:iiop::5500/CPRMsg
•  5500 is the port number on which the cpr server is running, according to the above output.

restarting the dataserver 

• It might  happen that the data tree could not be opened sometimes (in the local TS session). If so, you can enter the command dataserver and this will launch another fresh dataserver thread. You can access the tree then on.

about remote connections 

• If you are connecting to a remote TS server with a client, you have to make sure that the port into which you are connecting on the server is indeed the port at which the server is listening. To find this out, refer to the "smoking out the port on which the CPRserver is running" above.  If your remote connection is disabled from within Topspin on the remote server, you should enable the same by going to the Preferences - Misc - remote connections section.  You must restart Topspin on the remote server for your connection from a client to succeed.  

to kill ...license

Here is a simple trick that will come in handy for testing purposes.  It starts with the question :  will I be able to mimic a running Topspin host's configuration on a testbed machine so that I can install and run Topspin on this testbed without the need for a seperate license file i.e. by spoofing the testbed to be the original host in question.  The answer is yes and there are three important points to take care of :

• You must copy over the license.dat of the TS host into the testbed to the relevant location. 
  
• You must have a valid 'hostname' in the license.dat.  Since it is legal to chage this entry, you can set this to the testbed's hostname, specifically, to the name that is returned by `hostname` on the shell.
  
• You change the MAC id of the NIC, usually eth0 to that of the TS host, like so: 
• ifdown eth0
• ifconfig hw ether AA:BB:CC:DD:EE:FF  (where the MAC Id typed is the same as that of TS host).
• ifup eth0

  You might get an error message about the fact that the true MAC id and the spoofed one are different and the NIC may not come up at all.   Also, the MAC id spoofing is temporary and if you restart the network daemon, it reverts to the original.   For these two reasons at least,  this shortcut to inheriting an existing TS license is only a temporary indulgence.  But, this will come in quite handy to test run Topspin on the testbed, without imposing any down time on a running spectrometer.

Ok, let us wrap up the protocol fully :

• /etc/init.d/bruker_lmgr stop
• /etc/init.d/brker_lmgr start
• Now you can check under /usr/local/flexlm/Bruker/licenses, that the flexlm.log does show the daemon starting without any errors. 
• If you start topspin now, you should be able to get to the interface without any errors. 

As a closing thought, I will say this. In principle  you can exploit /etc/rc.local  to switch the MAC id after boot up and then restart lmgr to mimic the whole thing said above, in an automated fashion. But, since the NIC functionality is not expected to be smooth (as per my understanding thus far), this may not be a solution you look for on a permanent basis, anyway.

Printing active Topspin window works...now

TS2.1 PL4 was not playing well with RHEL v5.3, when it came to printing an active spectrum window onto the default printer.  The workaround was to use the XWINPLOT equivalent, which is invoked by 'plot' on the command line.

I confess that, although I sing the praise of XWINPLOT's virtues to new users, which  the software does deserve, after I started using the window dump feature of Topspin for a Q&D (i.e. quick and dirty) hard copy output, I find XWINPLOT to be a bit heavy.

I was getting a 'null attribute' error when I tried to dump the active window using ctrl+P and Brukerland asked me to check if I defined the default printer correctly. Yes I did, indeed, but to no avail.

What worked finally was this.

• Install the latest jre i.e. jre-1.6.0-sun, to be precise, at the time of writing.
• Soft link the same i.e. /usr/bin/java, again to be precise, to /opt/topspin/jre/bin/
• Hold it ! Before you go gung-ho, backup the java binary under the topspin tree to something recognizable like java.original and then do the above. Sure, I did not do this the first time around. The soft link did not fire up TS and I realized too late that the orignal java binary is gone.  I had to reinstall TS because of this. Although this is only a precaution, you can save the effort of finding the TS DVD and installing it, in case something goes wrong. See next bullet.
  
• By the way,  don't be over-zealous and go and link up the binary of the installed jre, which resides as : /usr/lib/jvm/jre-1.6.0-sun/bin/java. (Obviously, I tried this and screwed things up).   If you query for whereis java, you get the answer as :  /usr/bin/java.  Although /usr/bin/java is a link to another symlink that eventually points to the binary, you simply link /usr/bin/java to $TSHOME/jre/bin/ 
• Everything should work fine after this. I am able to do a screen dump without issues. 

Problem solved...