Building libbsd after installing libbsd

Chris Johns 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. 
> 

OK.

>     > + Then ./waf install and it will also rebuild some files before fails.
> 
>     Again which or is it both? 
> 
> libbsd only 

OK

>     > 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
>     built
>     > 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
>     build
>     > can avoid this, I think we need an error check early in the configure
>     process.
> 
>     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
>     reviewed.
> 
> It would be nice but I don't think that solves this. 

Agreed.

>     > I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is
>     installed
>     > 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.

Chris


More information about the devel mailing list