Re: Two build problems

[Noah Lavine]

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 <address@hidden> 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