Building libbsd after installing libbsd
chrisj at rtems.org
Sun Oct 11 22:29:42 UTC 2020
On 9/10/20 9:13 am, Joel Sherrill wrote:
> On Thu, Oct 8, 2020 at 4:59 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> On 9/10/20 8:24 am, Joel Sherrill wrote:
> > Hi
> > I am not sure if this is avoidable but it is surprising.
> > + build and install rtems to $prefix
> > + build and install libbsd to $prefix
> > + ./waf will then rebuild some files. It appears to be using installed headers
> Is this in rtems or libbsd?
> libbsd. RTEMS can be install and then "./waf" does nothing like you would expect.
> > + Then ./waf install and it will also rebuild some files before fails.
> Again which or is it both?
> libbsd only
> > I think there is no way to avoid this and waf for libbsd should detect that it
> > sees headers installed from itself and give an error that you need a clean
> > $prefix to build.
> Waf uses an md5 checksum for dependency checking so replacing a file with the
> same file should not trigger a rebuild, the contents have to have changed. This
> is different to make and others that stat a file.
> Then something is confusing it. The first build is with the file in the libbsd
> tree. Running waf again, I think it is using the installed one.
Oh OK. If the BSP is installed to the same prefix then this is hard to avoid.
> > Just to make sure there wasn't interference between two different BSPs, I
> > and installed one followed by a second different one. That went fine.
> > The behavior is bizarre and the weird compilation errors are mysterious until
> > you repeat the steps enough to figure it out. Unless someone knows how the
> > can avoid this, I think we need an error check early in the configure
> This implies some files in one package are overwriting a file installed by
> another package. That should not happen.
> It would be nice to install a manifesto of the files a package installs. I am
> sure it would aid deployment for those wanting to package and deploy RTEMS with
> rpm, deb or what ever else. It would help here as the contents of each could be
> It would be nice but I don't think that solves this.
> > I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is
> > already ad give a nice explanation and failure during configure.
> Adding this would limit those develop and maintaining these packages.
> The behavior now seems to confuse in-tree and installed header files is my guess.
I have not seen this. I am sure it does.
> > Thoughts?
> Should we understand the interactions before we decide on a solution?
> Sure. If there really is an avoidable bug.
It should be looked into and resolved.
More information about the devel