Bug 8283 - Cannot build a project based on ldb after compiling and installing it as standalone
Cannot build a project based on ldb after compiling and installing it as stan...
Status: RESOLVED INVALID
Product: Samba 4.0
Classification: Unclassified
Component: Build
unspecified
All All
: P5 trivial
: ---
Assigned To: Andrew Tridgell
samba4-qa@samba.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-03 04:17 UTC by Pierre Carrier
Modified: 2012-05-04 08:29 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Carrier 2011-07-03 04:17:14 UTC
Reproduced with samba.git, revision 7e52436673402095811eb081a0c036427fd31f84 (current master HEAD).

After:
$ cd source4/lib/ldb; ./configure; make; sudo make install

When trying to build anything linking to ldb, the build fails with:
--- 8< ---
In file included from ldb.c:2:
/usr/local/include/ldb.h:50:20: error: talloc.h: No such file or directory
/usr/local/include/ldb.h:51:20: error: tevent.h: No such file or directory
In file included from ldb.c:2:
/usr/local/include/ldb.h:81: error: expected specifier-qualifier-list before ‘uint8_t’
/usr/local/include/ldb.h:230: error: expected declaration specifiers or ‘...’ before ‘TALLOC_CTX’
/usr/local/include/ldb.h:318: error: expected ‘)’ before ‘*’ token
[...]
--- >8 ---

None of those find anything:
# find /usr/local/include -name talloc.h
# find /usr/local/include -name tevent.h

Obviously a trivial workaround is:
$ cd lib/talloc; ./configure; make; sudo make install; cd ../tevent; ./configure; make; sudo make install


Cheers,

-- 
Pierre
Comment 1 Brad Hards 2011-07-03 21:55:22 UTC
I guess that this was not what you were expecting.

Can you explain what you were expecting, and why?
Comment 2 Pierre Carrier 2011-07-03 23:43:02 UTC
IMHO it would make more sense to either depend on the deps to be built beforehand when building, or to install them along with ldb.

It feels like those 2 aspects are inconsistent:

- When running 'make', ldb dependencies are automatically built.
After that, tests can run and succeed as long as in the source tree.

- When running 'make install', ldb dependencies are not installed (or at least ldb deps headers are not installed).
AFAICT (but I never really got into the Makefile/wscript architecture in s4), there is no target to install them.


If that's really an expected behaviour and you consider it's not worth changing, please feel free to NOTABUG without further ado :)


-- 
Pierre
Comment 3 Jelmer Vernooij 2011-09-12 18:20:31 UTC
The standalone build doesn't build talloc/tdb as regular libraries but as "private" libraries (without version information, for example) that aren't usable by external users. 

Installing them by default might make it possible for you to use ldb itself, but wouldn't make it possible to link against those dependencies themselves - which you will need for certain things. 

I guess we could have the ldb build system install the other dependencies too, though I'm a bit hesitant to. There are some situations to watch out for though. E.g. what if a third party application links against the system talloc, but ldb decides to include its own because it considers the system one too old?
Comment 4 Pierre Carrier 2011-09-12 18:30:25 UTC
As it is, a standalone ldb is pretty much unusable with something like:

/usr/local/include/ldb.h:50:20: error: talloc.h: No such file or directory
/usr/local/include/ldb.h:51:20: error: tevent.h: No such file or directory

If ldb.h requires its own version of talloc.h and tevent.h, and the APIs themselves could very have changed between the internal version and the system one, I imagine there could very well be conflicts.

Shouldn't it have everything it needs from there declared in 'ldb.h' or 'ldb/*.h', with an ldb_ prefix for every name?
Comment 5 Jelmer Vernooij 2011-09-12 18:37:38 UTC
(In reply to comment #4)
> As it is, a standalone ldb is pretty much unusable with something like:

> /usr/local/include/ldb.h:50:20: error: talloc.h: No such file or directory
> /usr/local/include/ldb.h:51:20: error: tevent.h: No such file or directory
The "standalone" in ldb mainly means that it can be compiled independently of Samba, not that it does not have dependencies. It still requires talloc, tdb and tevent to be installed.

> If ldb.h requires its own version of talloc.h and tevent.h, and the APIs
> themselves could very have changed between the internal version and the system
> one, I imagine there could very well be conflicts.
The version of talloc/tevent/tdb that ldb includes is always a snapshot from the upstream git repository, there are no additional changes. However, ldb does depend on a minimum version of one of the other libraries.
Comment 6 Jelmer Vernooij 2011-09-12 18:40:18 UTC
Regardless of whether we want to support installing talloc/tdb/tevent from the standalone ldb build, I think we should for now:

* print a warning during configure to say that ldb won't be installable if we couldn't find certain libraries
* error out during "make install" if the other libraries aren't installed
Comment 7 Simo Sorce 2011-09-12 18:42:19 UTC
My personal preference would be for ldb to never build with private versions by default, but require external dependencies, with an override in case someone *really* want the private libs for some reason. After all if you are going to build ldb standalone you already understand you want the library on its own so you should be able to handle a few dependencies.
Comment 8 Jelmer Vernooij 2011-09-12 18:44:09 UTC
(In reply to comment #7)
> My personal preference would be for ldb to never build with private versions by
> default, but require external dependencies, with an override in case someone
> *really* want the private libs for some reason. After all if you are going to
> build ldb standalone you already understand you want the library on its own so
> you should be able to handle a few dependencies.
FWIW, that would be my preference too. We do have to worry about the build farm though, and that currently doesn't handle dependencies like this so we can't rip that out just yet.
Comment 9 Simo Sorce 2011-09-12 18:50:17 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > My personal preference would be for ldb to never build with private versions by
> > default, but require external dependencies, with an override in case someone
> > *really* want the private libs for some reason. After all if you are going to
> > build ldb standalone you already understand you want the library on its own so
> > you should be able to handle a few dependencies.
> FWIW, that would be my preference too. We do have to worry about the build farm
> though, and that currently doesn't handle dependencies like this so we can't
> rip that out just yet.

Yes the build farm would be one of those users that "*really* want the private libs for some reason", but it should use a switch to activate that behaviour, it shouldn't be the default.
Comment 10 Matthias Dieter Wallnöfer 2012-03-15 09:05:44 UTC
Any news here?
Comment 11 Matthias Dieter Wallnöfer 2012-05-04 08:29:05 UTC
I close this since there have not been any news for a while.