Re: librsvg fails to find cargo, no install but no error

On Tue, Nov 02, 2021 at 10:25:12PM +0100, Pierre Labastie wrote:
> On Tue, 2021-11-02 at 19:20 +0000, Ken Moffat wrote:
> > Hi Pierre, list,
> > 
> > I'm back trying to continue what is now a slightly old BLFS build to
> > check for issues and space requirements when building gnome (I
> > started out with space constraints where I'm backing up my images).
> > I've managed to sort most of the issues (including copying the
> > initial image to a bigger one after it filled up '/' in qt5 - hadn't
> > realised qt5 was pulled in for gnome).
> > 
> > However, librsvg is beating me.  The current set of scripts are to
> > build all of gnome on a system which started with openssh, xorg,
> > fluxbox.  Unsurprisingly, librsvg was early in the build and
> > apparently sailed through.  Last night I got to eog which complained
> > that its runtime dependency of librsvg-2 could not be found by
> > pkgconfig.  When I looked at the log from librsvg I was surprised to
> > see that it had failed to find cargo but apparently did not stop the
> > build even though the log ended with 'Error 2'.
> > 
> > Now that I know that rebuilding an early package will rebuild
> > whatever follows, I copied the script to just before eog and fixed
> > up the Makefile to invoke it.  Checking as my jhalfs user, cargo is
> > on the PATH.  So I added a couple of echos at the start of the
> > librsvg script to show the PATH and `type -pa cargo` (I think that
> > which has been installed, but I prefer the simple approach).
> > 
> > Similar result, althogh cargo was definitely present at the start of
> > the script. Again, the build continues and fails when eog cannot
> > find librsvg.  And yes, this is still rustc-1.52.0 because it's the
> > old version of the book.  Looking at the log, cargo was found during
> > the build, I can see it blocked waiting on the package cache and
> > then compiled various crates, but apparently the install failed to
> > find cargo.  Log follows:
> > 
> > PATH is /opt/rustc/bin:/usr/local/bin:/usr/bin:/opt/qt5/bin
> > cargo is at /opt/rustc/bin/cargo
> > [...]
> > make  install-recursive
> > make[1]: Entering directory '/sources/librsvg/librsvg-2.52.0'
> > Making install in .
> > make[2]: Entering directory '/sources/librsvg/librsvg-2.52.0'
> > cd . &&                                                 \
> > PKG_CONFIG_ALLOW_CROSS=1                                                \
> > PKG_CONFIG='/usr/bin/pkg-
> > config'                                                \
> > CARGO_TARGET_DIR=/sources/librsvg/librsvg-
> > 2.52.0/target                                 \
> > cargo --locked build   --release --bin rsvg-convert
> > /bin/sh: line 2: cargo: command not found
> > make[2]: *** [Makefile:1572: /sources/librsvg/librsvg-
> > 2.52.0/target/release/rsvg-convert] Error 127
> > make[2]: Leaving directory '/sources/librsvg/librsvg-2.52.0'
> > make[1]: *** [Makefile:1077: install-recursive] Error 1
> > make[1]: Leaving directory '/sources/librsvg/librsvg-2.52.0'
> > make: *** [Makefile:1388: install] Error 2
> 
> Problem is that if you use "sudo -E sh << ROOT_EOF", at this point, PATH is
> /usr/bin:/usr/sbin (or any default secure_path set in /etc/sudoers or
> /etc/sudoers.d) and does not contain /opt/rustc/bin anymore. Furthermore, since
> a new shell has been launched, set -e is not in effect so:
> - cargo is not found
> - the script does not exit although there is an error
> 
> I've been knowing this for a while, but too lazy to think of a way to fix it.
> when I have a problem with PATH after sudo -E, I usually add "source
> /etc/profile", which is somewhat overkill. And I live with non fatal errors...
> Since I think I was the only regular user of ablfs tools, I did not bother to
> change the script generation... But now that we are two of us, I think I can try
> to fix that.
> 
> I guess I should change to:
> sudo -E sh -e << ROOT_EOF
> PATH=$PATH:/usr/sbin
> ...
> 
> Needs some testing though.
> 
> Pierre
> 

Thanks.  I'll imaybe justadd 'source /etc/profile' when I get back
to this.  I'm not going to update anything, including jhalfs, I want
to complete soem main builds withi what were current versions of
everything to review my processes, and work out how best to keep a
handle on the things that the book does not nicely handle for
jhalfs.

Might be a while, that machine is powered off at the moment, I'm
currently updating on a different machine and looking at a kernel
patch.

ĸen
-- 
Vetinari smiled. "Can you keep a secret, Mister Lipwig?"
"Oh, yes, sir. I've kept lots."
"Capital. And the point is, so can I. You do not need to know.”

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page