Building libbsd after installing libbsd
joel at rtems.org
Thu Oct 8 22:13:00 UTC 2020
On Thu, Oct 8, 2020 at 4:59 PM Chris Johns <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
> Is this in rtems or libbsd?
libbsd. RTEMS can be install and then "./waf" does nothing like you would
> > + Then ./waf install and it will also rebuild some files before fails.
> Again which or is it both?
> > 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
> > $prefix to build.
> Waf uses an md5 checksum for dependency checking so replacing a file with
> same file should not trigger a rebuild, the contents have to have changed.
> 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.
> > Just to make sure there wasn't interference between two different BSPs,
> I built
> > and installed one followed by a second different one. That went fine.
> > The behavior is bizarre and the weird compilation errors are mysterious
> > you repeat the steps enough to figure it out. Unless someone knows how
> the build
> > 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
> sure it would aid deployment for those wanting to package and deploy RTEMS
> 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
> > Thoughts?
> Should we understand the interactions before we decide on a solution?
Sure. If there really is an avoidable bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel