I have found the cause of the second problem, but I'm not sure what to do about it. Here's what's happening:
libguile/bytevectors.c includes <uniconv.h>. uniconv.h lives in my system include directory (~/.nix-profile/include, actually). It includes a file called "unitypes.h". That refers to ~/.nix-profile/include/unitypes.h, which does the usual #ifdef UNITYPES_H ... #endif trick to avoid being included more than once. But then on the next line, libguile/bytevectors.c includes <unistr.h>. That refers to lib/unistr.h, not the system unistr.h. lib/unistr.h also includes "unitypes.h", but the version of unitypes.h in lib/ is different than my system version. However, the version of unitypes.h in lib/ is never used, because it also has a #ifdef UNITYPES_H ... #endif wrapper. So lib/unistr.h doesn't get some #defines it needs, which causes a build failure. So that's the issue. What is the correct solution? Thanks a lot, Noah On Sat, Sep 15, 2012 at 2:40 PM, Noah Lavine <noah.b.lav...@gmail.com> wrote: > Hello, > > I hit two errors while building recent Guile, one of which I have diagnosed. > > First problem: > > At first, I couldn't build lib/striconveh.c. Here's what I think was > wrong: Make doesn't know that lib/striconveh.c depends on > lib/unitypes.h. This is a problem because lib/unitypes.h is generated > from lib/unitypes.in.h, but because Make doesn't know about the > dependency, it doesn't bother to generate lib/unitypes.h before > building striconveh.c, thus generating an error. > > Here's some evidence that this is true: when I manually make > lib/unitypes.h and then make Guile the regular way, the build > succeeds. (I actually decided this by manually following the includes > and noticing that lib/unitypes.h doesn't exist, then looking in the > Makefile to find out why.) > > I'm not quite sure what the right fix is, for two reasons. First of > all, the dependency isn't direct - lib/striconveh.c includes > lib/unistr.h, which then includes lib/unitypes.h. So maybe > lib/unistr.h should depend on lib/unitypes.h, and striconveh.c > shouldn't be directly involved. Second, I believe lib/ actually comes > from gnulib, and I don't know how that's organized. So I don't know if > this is a Guile bug or a gnulib bug. > > Second problem: > > Since I could fix the first one by hand, I decided to go ahead and > build Guile. That's when I discovered that even though lib/unitypes.h > exists, it's not being included by lib/unistr.h when building files in > the libguile/ directory (even though it works fine when building > things in the lib/ directory). Therefore, an include path is messed up > somewhere. > > lib/unistr.h says this: #include "unitypes.h". > > But when I try to build bytevectors.c, I get lots of errors from > lib/unistr.h that seem to be based on a lack of macros from > lib/unitypes.h. As an experiment, I added the line "#error" to > lib/unitypes.h. As expected, the preprocessor and compiler didn't > compain about it, which I think means that they're never looking in > lib/unitypes.h when building libguile/bytevectors.c. This is a > problem. > > Unfortunately, I don't know how to fix this one. Defining the macro > INCLUDES in libguile/Makefile to -I../lib:./lib doesn't seem to help. > > Thanks, > Noah
