Two build problems

Two build problems

[Noah Lavine]

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

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 <noah.b.lavine@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

Re: Two build problems

[Ludovic Courtès]

Hi Noah,

This vaguely rings a bell...

Noah Lavine <noah.b.lavine@gmail.com> skribis:

> libguile/bytevectors.c includes <uniconv.h>.
>
> uniconv.h lives in my system include directory

[...]

> But then on the next line, libguile/bytevectors.c includes <unistr.h>.
> That refers to lib/unistr.h, not the system unistr.h.

Could it be that lib/unitstr.h is a left-over from a previous build?

Can you check whether the problem exists when building from a fresh
checkout?  (Hydra is happy, FWIW...)

Thanks,
Ludo’.

Re: Two build problems

[Noah Lavine]

Guile seems to build fine after "make distclean", so I guess the
problem was left-over files. I may also have installed another package
in an attempt to work around this, though. I'd rather not try
reverting package installs to see if I can break it again.

It's an unusual problem - in order to reproduce it, you have to have a
system with two distinct library directories, one of which has
uniconv.h but not unistr.h, and they have to have different
definitions of unitypes.h. I don't know of a good solution, but I
don't think it's worth worrying about right now. It should never occur
for distro builds of Guile, because they will be packaging all of
their libraries together, so they'll only have one version of
uniconv.h.

Noah

On Wed, Sep 26, 2012 at 5:41 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi Noah,
>
> This vaguely rings a bell...
>
> Noah Lavine <noah.b.lavine@gmail.com> skribis:
>
>> libguile/bytevectors.c includes <uniconv.h>.
>>
>> uniconv.h lives in my system include directory
>
> [...]
>
>> But then on the next line, libguile/bytevectors.c includes <unistr.h>.
>> That refers to lib/unistr.h, not the system unistr.h.
>
> Could it be that lib/unitstr.h is a left-over from a previous build?
>
> Can you check whether the problem exists when building from a fresh
> checkout?  (Hydra is happy, FWIW...)
>
> Thanks,
> Ludo’.
>
>