Using the most up-to-date version of gcc (4.4.2) and glibc (2.11-r1), molden fails to build. One specific problem is with the xwin.c file where at line 3779 there is a redeclaration of linkat which conflicts with the definition on line 812 in unistd.h. There are other warnings regarding xwin.c suggesting there are some typing problems with format strings (line 12832), some ignored return values that could be easily fixed and at leas 4 warnings in eem.f regarding the use of the obsolete "assign" statement. In general they suggest that there needs to be some serious interaction between the Gentoo developers and the Molden developers that the package needs to be upgraded to "current" compiler standards. The error exists whether or not the opengl USE flag is used. Reproducible: Always Steps to Reproduce: 1. emerge molden 2. fails to build Actual Results: Fails to compile xwin.c Expected Results: Should build the package. Minimally needs patches or constraints on the version of glibc (unistd.h) or some additional CFLAGS so linkat is not declared in unistd.h. If old (legacy) packages don't build with current compilers and the original developers don't maintain them then the Gentoo developers need to pick up the slack with patches or the package needs to be masked/removed (determining if more up-to-date replacements are available).
Ok, I did some more research into this. The problem is a local variable "linkat" and the problem can be corrected via a simple global edit of xwin.c: g/linkat/s//mylinkat/g After that, with some creativity you can build molden, moldenogl and gmolden. The current gentoo ebuild does not appear to build gmolden for some reason. I suspect one could improve the package by producing a shared library for the bulk of the package and just have all 3 binaries reference the shared library (it would save a 2-4 MB in /usr/bin). It does appear to run, though I haven't tested it extensively. Until a patch is provided (or portage gets some useful "restart" capabilities) I think one has to do the patch by hand and hack together the loads by hand (the makefile appears to want g77 (and however things are setup a simple symbolic link from g77 to /usr/bin/gfortran doesn't do the trick) [something about gcc-config getting involved.] Note that if gfortran does have some Fortran 77 switches that might reduce the warnings produced.
*** This bug has been marked as a duplicate of bug 270941 ***
