Re: gub: I can now completely build lilypond

[Werner LEMBERG]

Regarding Knut's compilation problems on gub with guile:

>> In file included from
>>   
>> /home/gub/NewGub/gub/target/darwin-x86/src/guile-1.8.7/libguile/strings.h:25:0,
>>   from /usr/include/string.h:431,
>>   from
>>   
>> /home/gub/NewGub/gub/target/darwin-x86/src/guile-1.8.7/libguile/gen-scmconfig.c:127:
>> /home/gub/NewGub/gub/target/darwin-x86/src/guile-1.8.7/libguile/__scm.h:52:10:
>>   fatal error: libguile/scmconfig.h: No such file or directory
>>   #include "libguile/scmconfig.h"          ,
>>            ^~~~~~~~~~~~~~~~~~~~~~
> 
> You'll receive the relevant log and strace file in a separate mail.

Thanks.  As far as I can tell, the problem is as follows.

`gen-scmconfig' (and `c-tokenize') will be run on the build host.  For
this reason, it gets compiled with $CC_FOR_BUILD if cross compiling.
`guile.py' in gub sets this to

    CC_FOR_BUILD="\
      LD_PRELOAD= \
      C_INCLUDE_PATH= \
      CPPFLAGS= \
      LIBRARY_PATH= \
      PATH_SEPARATOR=':' \
      PATH=/usr/bin:$PATH \
      /usr/bin/cc -I%(builddir)s \
                  -I%(srcdir)s \
                  -I%(builddir)s/libguile \
                  -I. \
                  -I%(srcdir)s/libguile"

On openSUSE tumbleweed, you are using gcc 8 with a more recent libc
version.  Contrary to my older openSUSE box, the file
`/usr/include/string.h' seems to also include a file `strings.h'.
However, due to the `-I%(srcdir)s/libguile' option, it finds
libguile's `strings.h' file first[*]

Looking into `libguile/gen-scmconfig.c' I see

    #ifdef HAVE_CONFIG_H
    #  include <config.h>
    #endif

    #include <libguile/gen-scmconfig.h>

    #include <stdio.h>
    #include <string.h>

which means that no local header file from the `libguile' directory is
used (ditto for `c-tokenize').  If you thus remove

  -I%(srcdir)s/libguile

and also probably

  -I%(builddir)s/libguile

from $CC_FOR_BUILD, compilation should succeed.

Please check whether my analysis holds.


    Werner


[*] I consider it a very, very bad idea to use such generic header
    file names in a project...