ctags 5.8 creates improper tags file when compiled with llvm

[echosa@…]

So, as the summary says, ctags 5.8 creates improper tags files when compiled on OS X Lion using the Lion .dmg macports install. However, on Snow Leopard, compiled with the Snow Leopard version of macports, the created tags files are correct. The Lion-compiled ctags binary has the same issues on Snow Leopard, and the Snow Leopard-compiled binary works fine on Lion. (So right now, I'm just using a ctags binary compiled on Snow Leopard to get my work done on Lion.)

Here's the command I'm running from my project's root directory:

/opt/local/bin/ctags -e -f /path/to/TAGS -R --tag-relative=yes --totals=no --langmap=php:.php --exclude=.svn --PHP-kinds=+cf .

I'm running this on a PHP project, obviously. Also, you'll notice the -e flag, making the TAGS file etags compatible.

A proper etags reference should basically be of the format:

<file>,<size of tag entry>
<tag information>

A TAGS file will contain many of these.

Here's an example of what the ctags compiled with Snow Leopard is (properly) generating.

../../../Volumes/webdev/biosafety/trunk/application/Bootstrap.php,78
class Bootstrap extends Zend_Application_Bootstrap_BootstrapBootstrap33,719
(... extra lines here for the rest of this tag's information ...)

The important thing here is the path at the beginning.

The ctags compiled on Lion, however, doesn't always have this proper format. Sometimes the path will be /var/some/temp/path/somewhere or, more often, will be nonexistent, like this:

,78
class Bootstrap extends Zend_Application_Bootstrap_BootstrapBootstrap33,719
(... extra lines here for the rest of this tag's information ...)

Notice there is no file reference before the first comma. Note that not all of the tags references are bad. Some are proper, a few have paths to /var/somewhere, but the rest have no file reference at all.

FYI, the way I'm viewing these TAGS files is by loading them in emacs with visit-tags-table and switching to their buffer, which allows them to be seen in plain text.

[ryandesign@…]

Please remember to use WikiFormatting, and to Cc the maintainer of the affected port.

[echosa@…]

Sorry about that. First submission, didn't read the guide very carefully. Won't make the same mistake again. Thanks for correcting.

[tim.blackman@…]

Related bug report on the ctags project site:

​https://sourceforge.net/tracker/index.php?func=detail&aid=3247256&group_id=6556&atid=106556

As I noted there, it looks like using the standard compiler but disabling optimization is an effective work around:

export CFLAGS=-O0

Then configure and make as usual.

[cal@…]

Sounds like a clang problem to me; try installing with port install ctags configure.compiler=llvm-gcc-4.2 and report back if the issue doesn't happen in this installation.

Note that MacPorts mostly ignores environment variables, as it sets its own ones. If you wanted to disable optimization for MacPorts-compiled binaries use port install ctags configure.optflags=-O0.

[echosa@…]

Running port install ctags configure.compiler=llvm-gcc-4.2 doesn't change anything.

However, running port install ctags configure.optflags=-O0 fixes the issue, as does using -O1. Compiling with -O2 results in the issue.

[jmr@…]

Workaround based on the info in comment:5 committed in r93604. Really needs to be fixed upstream though.

[jeremyhu@…]

Do you have a test case that shows off this issue (like a tarball and a command to run)? I'd like to determine if it is fixed in newer versions of clang, and if not, we need to report this upstream.

[jeremyhu@…]

Cc Me!