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
I guess that this was not what you were expecting. Can you explain what you were expecting, and why?
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
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?
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?
(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.
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
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.
(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.
(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.
Any news here?
I close this since there have not been any news for a while.