[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dependent libraries

From: Stefano Lattarini
Subject: Re: Dependent libraries
Date: Fri, 02 Nov 2012 10:04:59 +0100

On 10/31/2012 09:36 PM, Murray S. Kucherawy wrote:
> Hi,
> I know there are other threads on this topic already, but they don't
> seem to match my situation exactly, so I hope people don't mind a bit
> of a repeat.
> My top-level directory contains source for several libraries and a
> binary.  One of the libraries depends on the other, but so too do the
> binaries and their respective test programs. That is:
> libx/
>   xsrc.c
>   x.h
> liby/
>   ysrc.c (tries to #include <x.h>)
> bin1/
>   bin1src.c (tries to include <x.h>)
> bin1/tests/
>   test1.src (tries to include <x.h>)
> bin2
>   bin2src.c (tries to include <x.h>)
> libx/ tries to install x.h in a subdirectory off of
> $includedir.  During "make", gcc for ysrc.c gets -I../libx, so the
> build is fine.  During "make distcheck" however, the build of ysrc.c
> can't find x.h, and terminates.
> The suggestion I've seen for dependent libraries is to make libx be a
> SUBDIR of liby.  I could do this, but it brings up two questions:
> (a) Will bin1/, bin1/tests/, and bin2/ be able to find <x.h> during
> "make distcheck"?
> (b) There are other libraries in the package that might become
> dependent on libx later.  The SUBDIR wouldn't work in this case, I
> take it.  Is there a solution when i get to that point, apart from
> making libx into its own separate package?
> Thanks,
> -MSK
I guess we might understand the issue better if you posted the actual
content of your files.  It's harder to understand where
the problem might be without seeing the code that is causing it ...

That said, a wild shot: maybe a proper use of AM_CPPFLAGS might help?
For some inspiration see:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]