In versions from 5.6 onwards on OSX Lion there are problems when generating an emacs TAGS file, even if you simply pass -x to show the table.
The output always contains (possibly in addition to other errors), the line:
(null),22
(where 22 might be a different number depending on the file)
I tested this with the simplest possible files. When called with a list of files (-L) or recursively on a directory, only the first file seems to generate this invalid tag (but other invalid entries exist, such as "^^,120" and "/var/folders/m7/6b_4vfzx06b9mg52lc9d31r0001jmd/T//tags.l1LmvG,2960".
I have tried configuring using --disable-external-sort.
I am unable to configure versions before /tags/CTags-5_6 because of errors during configure (cannot find ./install.sh, unable to guess build system).
This problem seems to be specific to the LLVM compiler that ships with Xcode 4.3.2 on Max OS X Lion. It's not clear to me if this is a bug in Exuberant, or the compiler. But I was able to get a non-buggy version of Exuberant built on my Lion box with a version of the GCC compiler I built from scratch, following these instructions:
http://staticimport.blogspot.com/2012/02/building-gcc-462-on-os-x-lion.html
sullymandias: I happened to have an alternate gcc (4.6) compiler installed already and when I switched to using that... lo and behold I have working ctags.
I will send a message to the fink maintainer as well.
Thanks!
Has anyone made any progress in isolating the root cause of this issue? The compiler, or the source code?
See my comment #3 under;
https://sourceforge.net/tracker/?func=detail&aid=3247256&group_id=6556&atid=106556
I suspect strongly that the problem is caused by strcpy copying overlapping strings.
This the patch MacPorts is using to fix the overlapping strcpy problem:
https://github.com/macports/macports-ports/blob/5f57b2016ff9b894b179dd3b29cc1eb6f714096f/devel/ctags/files/strcpy_overlap.patch