VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Sun Oct 08 2000 - 22:49:58 CDT

Hi,
  I'm in a rush and can't give your note adequate attention just
now, but we definitely appreciate your comments and analysis on your
experience with Redhat 7 so far. I believe your VMD startup crash is
due to dynamic linking problems which are apparently a well known issue
for people running software compiled on other versions of Linux. In
particular RH7 uses a version of gcc and link libraries which have been
said to have backwards compatibility problems:
  http://slashdot.org/article.pl?sid=00/10/07/0027218&mode=thread

I'm also confused as to when it became practicable for anyone to be putting
exception handling semantics on top of the ancient Unix routines such as
isatty() etc. In any case, I know a way to avoid this problem, and we'll
be changing how the AtomLexer/AtomParser code are compiled so that the RH7
include files (Which I'd say are broken!) don't break VMD compiles.

In the mean time, I recommend that people think twice before upgrading
to RH7, I've also heard there are issues with the XFree version that they
are shipping with as far as hardware 3-D goes.

We'll probably have our code changed to avoid the RH7 lex/yacc problem
(and others) in a week or two.

Thanks,
  John Stone
  vmd_at_ks.uiuc.edu

On Sat, Oct 07, 2000 at 01:57:48AM -0400, John Duff wrote:
> Hello,
>
> I've run into a bug when trying to compile vmd using redhat 7.0 (i386).
>
> System
> ------
> 800MHz Athlon TBird (Abit KT7 mobo)
> 256M Atlas Precision RAM
> Creative Labs 3D Blaster Annihilator 2 vid card (NVIDIA GeForce 2 GTS 32M DDR)
> RedHat 7.0 (2.2.16-22 kernel)
> XFree86 4.0.1
> NVIDIA linux 0.9.5 drivers
>
>
> Synopsis
> --------
> After downloading the precompiled vmd1.6a3 Linux DRI-OpenGL package, I
> configured and installed it, but when I ran it, it immediately died after
> very briefly popping up the console window. This seems to be a known problem
> (http://www.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/0093.html). I tried
> fixing up the links to libGL.so like the mailing list email suggested, but
> still it didn't work. So I downloaded the source and when I tried compiling
> I got the following error message:
>
> Converting AtomLexer.l --> AtomLexer.o ...
> lex.yy.c:1659: declaration of `int isatty (int)' throws different
> exceptions
> /usr/include/unistd.h:670: than previous declaration `int isatty (int)
> throw ()'
> make: *** [AtomLexer.o] Error 1
>
>
> After investigating this, I found the following (quick and dirty) workaround.
> Modify line 670 in /usr/include/unistd.h:
>
> <from>
> extern int isatty (int __fd); __THROW;
> <to>
> extern int isatty (int __fd);
>
>
> After I did this, vmd compiled smoothly and started up without any problems
> after doing a "make install". Note that after compiling vmd, you should
> undo the change to line 670 in unistd.h, as this is not a bug in unistd.h.
>
>
> More Details
> ------------
> Obviously the fix is a quick hack just to enable vmd to compile.
>
> /usr/include/unistd.h is in the glibc-devel-2.1.92-14 package. It looks
> like all the function prototypes in unistd.h now have "__THROW" appended
> to them, which is something new in this file, different from the version in
> the package found in RedHat 6.2 (glibc-devel-2.1.3-15). Furthermore, __THROW
> is defined in /usr/include/malloc.h, and it resolves to "throw" only if you're
> compiling C++ programs, which makes sense. VMD's Makefile first uses lex
> to compile the AtomLexer.l file to lex.yy.c, renames lex.yy.c to lex.yy.C,
> and then uses g++ to compile lex.yy.C. That looks like the source of the
> problem, since the use of g++ causes __THROW to be "throw" instead of "" in
> the prototype of isatty (line 670 /usr/include/unistd.h), which is different
> than the C prototype of isatty in lex.yy.c (line 1659). I tried fixing
> the Makefile to use gcc instead of g++ to compile lex.yy.c, but it looks like
> AtomLexer.l includes Inform.h, which is a C++ header file (I guess that's
> why you used g++ to compile it). So, if all this is accurate, it looks like
> you need to fix AtomLexer.l to be able to be compiled using a C compiler,
> not C++.
>
>
> -John
> jfduff_at_mtu.edu 

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078