#262 Tag generation always use 32-bit compiler on 64-bit linux

pending
nobody
General (289)
5
2012-09-14
2009-02-06
Anonymous
No

Geany 0.15 (64-bit), Linux x86_64 2.6.28

As the summary says, geany tag generation always use a 32-bit compiler on 64-bit Linux. For example, have the following header file:

--- foo.h ---
#ifdef __LP64__
void foo64 (void);
#else
void foo32 (void);
#endif
-------------

Running 'geany -g' to generate tags from this file makes a symbol for foo32, not foo64 as expected.

If the compiler doesn't support 32-bit compilation (as is the case on Arch64), tag generation usually aborts with an error (missing gnu/stubs-32.h).

The geany executable is 64-bit.

Discussion

  • Enrico Tröger
    Enrico Tröger
    2009-02-10

    Tested and confirmed.
    Geany doesn't really use 'a 32bit compiler' instead when generating tags files for C and C++, it passes the specified header files through the C preprocessor using the '-undef' command line option. This flag causes the preprocessor to not set architecture dependent macros which actually causes the described behaviour.
    Anyway, we need the '-undef' flag to properly generate C tags files.

    For creating custom tags files, try adding the '-P' command line option to Geany which disables using the preprocessor, this should result in a tags file with both foo32 and foo64 tags because the parser then reads the symbols by ignoring #ifdef macros.

    Alternatively, you can manually define the __LP64__ macro, e.g.:
    CFLAGS="-D__LP64__" geany -g foo.c.tags /tmp/foo.h

    And after all, the error message about missing gnu/stubs-32.h is rather harmless, Geany will create a valid and (almost) complete tag file anyway. I tested this on Debian Unstable with a multilib gcc and on ArchLinux with its plain 64bit gcc.

     
  • Thanks for your reply, eht16.

    The small header I posted was just a minimal example. Putting -D__LP64__=1 in CFLAGS works for that, but doesn't fix other things, like the gnu-stubs32.h error message (turns out that one depends on __WORDSIZE to be set to 64, but putting -D__WORDSIZE=64 doesn't work. I'm guessing the __WORDSIZE macro is undefined and reset based on something else). Using -P means #include doesn't work, and defines are important sometimes.

    Anyway, it looks like this is just a symptom of the real problem, which is that -undef removes many definitions that headers rely on to work properly. And sorry, but it IS a real problem... The error seemed harmless to me too at first, but later on I discovered that symbols were missing. For example, generating tags from opengl headers fails to include some symbols. -undef even undefines basic things like __linux__, which means that cross-platform headers that rely on that to include the right things no longer works. Now that I know what's causing all these missing symbols I can at least hunt around in the headers to try to find out what define needs to be set, but it'd be nice to not have to do this. Is there no way you can avoid having to use -undef?

     
  • Enrico Tröger
    Enrico Tröger
    2009-02-27

    I see your point, but we need the '-undef', without for instance the generation of the c99 tags doesn't work correctly anymore.
    If it helps, we could add a command line option to Geany to not pass the '-undef' argument to the preprocessor if specified.

     
  • Lex Trotman
    Lex Trotman
    2012-09-14

    Is this still an issue? Can someone who has appropriate compilers please test. Otherwise will be closed as out of date.

     
  • Lex Trotman
    Lex Trotman
    2012-09-14

    • status: open --> pending