| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
On 11/2/21 3:25 PM, Pierre Labastie ([email protected] via alfs-discuss Mailing
List) 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.
In /etc/sudoers, add:
Defaults !secure_path
-- Bruce
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page