The problem is with the header file string.h, which apparently defines a function 'index', which is incompatible with the fact that LiE uses the same name as a type. <rant> The name 'index' is not reserved in any way in ANSI C, and since the LiE makefile calls the gcc compiler with the -ansi flag for all files that use 'index', which tells it that the source adheres to strict ANSI/ISO C and has no desire to use anything else, the symbol 'index' should not get defined when #include <string.h> is executed. The flag -ansi is there specifically for this purpose (accoring to the gcc manpage, this flag indicates that the program conforms to the ISO C90 standard, and the compiler should take measures to recognise it as such), so it would seem to me that if 'index' still gets defined globally as a function, your system is broken, and you should complain loudly to your vendor. If you are experiencing this problem, it shows that so far nobody has complained loudly enough about it. If you did complain but they told you the problem is not theirs, please ask them to explain to me why it should be mine. I could never have guessed the kludge of adding -D_ANSI_SOURCE (delimited by spaces) after -ansi in the line of the Makefile that starts with 'all-C-flags:=' had I not had the occasion to look at the system header files on a Mac. There may be other broken systems out there that require a different kludge, how can I know? </rant>
Here is one more word of explanation. Among other things the gcc compiler translates the prensence of a command line flag -ansi into defining the symbol __STRICT_ANSI__, which should exclude conflicting pieces of header files. On Mac OS X however, the relevant poritions of the header files appear to get excluded if (and only if) _ANSI_SOURCE is defined. This seems to me to be a blatant confusion between the conventions used by the compiler and by the header files on OS X, and I am surprised that other software more popular than LiE has not brought this problem to the attention of the people responsible for this.
There are also some possible issues with the GNU readline library, but I do not have sufficient details to comment on this. In any case the LiE interface to the readline library is absolutely minimal (the currently distributed version does not even do any form of command completion), so any problems you might encounter are probably not LiE specific.