> I would call these ones bugs in the current Makefile.in.
yes, it's all fixable. The level of effort involved in fixing all
these things may not be small however.
I think Kai has noticed some other s3 build bugs as well while he's
been developing the waf build for s3.
> > - bundled library renames, so they can safely install on a system
> > that has packages that rely on talloc, tdb etc without breaking
> > their system
> What does that mean?
I tried to explain it a bit on the wiki page:
The problem is this. Imagine you are building tdb as a shared lib in
Samba3, and the build decides to use the in-tree version instead of
the system version as the system version is too old.
So you end up with libtdb.so. Then you install that in
Now you have a problem. What do you put in ld.so.conf? If you put
/usr/local/samba/lib first then any existing apps that depend on tdb
will get the new version. That will be a version they've never been
tested against. If you don't put /usr/local/samba/lib first then Samba
will get the system version.
So the solution is to auto-rename the library to something else. In
the waf build a suffix is added, based on the name of the package
being built. So if you are building libtdb.so as part of a s4 build
then you end up with libtdb-samba4.so. That guarantees no conflicts,
and ld.so.conf can contains paths in any order.
> What blocks us from putting that into Makefile.in as well?
nothing. We could have just kept going with autotools, and s3 can keep
going with autotools if that is what we decide to do as a team.
I'm hoping that the new build system will make life easier for
> > - detection of conflicts between system and in-tree libs, so you
> > don't end up with two instances of talloc in one binary (and thus
> > possible corruption)
> Again, this is a bug in the Makefile.in.
sure, and it is fixable, though I don't think its a trivial patch to