Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
I don't understand this "preserved rebuild" / epl thing
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
thurnax
Tux's lil' helper
Tux's lil' helper


Joined: 17 Apr 2014
Posts: 90

PostPosted: Wed Nov 01, 2017 9:05 am    Post subject: I don't understand this "preserved rebuild" / epl Reply with quote

I get this message after an emerge update:

Code:
!!! existing preserved libs:
>>> package: sys-libs/ncurses-6.0-r1
 *  - /lib64/libncurses.so.5
 *  - /lib64/libncurses.so.5.9
 *      used by /lib64/libgpm.so.1.20.0 (sys-libs/gpm-1.20.7-r2)
 *      used by /usr/bin/emacs-24 (app-editors/emacs-24.5-r3)
 *      used by /usr/games/bin/frotz (games-engines/frotz-2.43)
>>> package: dev-libs/boost-1.62.0-r1
 *  - /usr/lib64/libboost_program_options.so.1.56.0
 *      used by /usr/bin/akonadi_agent_launcher (kde-apps/akonadi-1.13.1_pre20160203-r1)
 *      used by /usr/bin/akonadi_agent_server (kde-apps/akonadi-1.13.1_pre20160203-r1)
 *      used by /usr/bin/akonadi_control (kde-apps/akonadi-1.13.1_pre20160203-r1)
 *      used by 4 other files
>>> package: sys-libs/binutils-libs-2.28.1
 *  - /usr/lib64/libbfd-2.25.1.so
 *      used by /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so (sys-devel/binutils-2.25.1-r1)
Use emerge @preserved-rebuild to rebuild packages using these libraries
 * After world updates, it is important to remove obsolete packages with
 * emerge --depclean. Refer to `man emerge` for more information.


If I issue an "emerge @preserved-rebuild", what will happen is that binutils will be downgraded to 2.25, boost 1.56 and ncurses to 5.9. An output of the rebuild looks like so:

Code:
# emerge @preserved-rebuild --ask

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by @preserved-rebuild (argument)
# /usr/portage/profiles/package.mask:
# Michał Górny <mgorny@gentoo.org>, Andreas K. Hüttel <dilfridge@gentoo.org>,
# Matthias Maier <tamiko@gentoo.org> (21 May 2017)
# These old versions of toolchain packages (binutils, gcc, glibc) are no
# longer officially supported and are not suitable for general use. Using
# these packages can result in build failures (and possible breakage) for
# many packages, and may leave your system vulnerable to known security
# exploits.
# If you still use one of these old toolchain packages, please upgrade (and
# switch the compiler / the binutils) ASAP. If you need them for a specific
# (isolated) use case, feel free to unmask them on your system.
=sys-devel/binutils-2.25.1-r1

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.

Would you like to add these changes to your config files? [Yes/No] no

 * In order to avoid wasting time, backtracking has terminated early
 * due to the above autounmask change(s). The --autounmask-backtrack=y
 * option can be used to force further backtracking, but there is no
 * guarantee that it will produce a solution.

emerge: there are no ebuilds to satisfy "kde-apps/akonadi:0".

It wants me to unmask binutils 2.25.

I don't want that.

So how can I clean this out without downgrading packages needlessly?
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 3720
Location: Germany

PostPosted: Wed Nov 01, 2017 9:13 am    Post subject: Reply with quote

Please try this --> https://forums.gentoo.org/viewtopic-p-8133466.html#8133466
Back to top
View user's profile Send private message
thurnax
Tux's lil' helper
Tux's lil' helper


Joined: 17 Apr 2014
Posts: 90

PostPosted: Wed Nov 01, 2017 9:21 am    Post subject: Reply with quote

Too late. :(

I managed to get rid of most errors by emerge --oneshot on most of these packages except emacs and binutils. So I unmerged those packages to try to re-emerge them. Now both packages fail to rebuild. When trying to build binutils, I get this output:

Code:
# emerge --nodeps sys-devel/binutils

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-devel/binutils-2.28.1::gentoo
 * binutils-2.28.1.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                                     [ ok ]
 * binutils-2.28.1-patches-1.0.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                          [ ok ]
>>> Unpacking source...
>>> Unpacking binutils-2.28.1.tar.bz2 to /var/tmp/portage/sys-devel/binutils-2.28.1/work
>>> Unpacking binutils-2.28.1-patches-1.0.tar.xz to /var/tmp/portage/sys-devel/binutils-2.28.1/work
>>> Source unpacked in /var/tmp/portage/sys-devel/binutils-2.28.1/work
>>> Preparing source in /var/tmp/portage/sys-devel/binutils-2.28.1/work/binutils-2.28.1 ...
 * Applying various patches (bugfixes/updates) ...
 *   00_all_0001-ld-always-warn-about-textrels-in-files.patch ...                                                                                                                                   [ ok ]
 *   00_all_0002-gold-ld-add-support-for-poisoned-system-directories.patch ...                                                                                                                      [ ok ]
 *   00_all_0003-ld-enable-new-dtags-by-default-for-linux-gnu-targets.patch ...                                                                                                                     [ ok ]
 *   00_all_0004-gold-ld-enable-gnu-hash-by-default.patch ...                                                                                                                                       [ ok ]
 *   00_all_0005-libiberty-install-PIC-version-of-libiberty.a.patch ...                                                                                                                             [ ok ]
 *   00_all_0006-opcodes-link-against-libbfd.la-for-rpath-deps.patch ...                                                                                                                            [ ok ]
 *   00_all_0007-CVE-2017-8398.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0008-CVE-2017-8393.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0009-CVE-2017-8394.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0010-CVE-2017-8395.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0011-CVE-2017-8396-CVE-2017-8397.patch ...                                                                                                                                              [ ok ]
 *   00_all_0012-CVE-2017-8421.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0013-CVE-2017-9038.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0014-CVE-2017-9039.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0015-CVE-2017-9040-CVE-2017-9042.patch ...                                                                                                                                              [ ok ]
 *   00_all_0016-CVE-2017-9041.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0017-CVE-2017-7614.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0018-CVE-2017-6965.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0019-CVE-2017-6966.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0020-CVE-2017-6969.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0021-fix-out-of-bounds-access-in-elf.c.patch ...                                                                                                                                        [ ok ]
 *   00_all_0022-fixing-linking-configure-generated-tests-of-ifunc.patch ...                                                                                                                        [ ok ]
 *   00_all_0023-readelf-dont-error-on-.debug-files-with-NOBITS-.dynamic-sectio.patch ...                                                                                                           [ ok ]
 *   00_all_0024-CVE-2017-9742.patch ...                                                                                                                                                            [ ok ]
 *   00_all_0025-CVE-2017-9954.patch ...                                                                                                                                                            [ ok ]
 * Done with patching
 * Fixing misc issues in configure files
 * Using GNU config files from /usr/share/gnuconfig
 *   Updating config.sub                                                                                                                                                                            [ ok ]
 *   Updating config.guess                                                                                                                                                                          [ ok ]
 * Running elibtoolize in: binutils-2.28.1/
 *   Applying portage/2.2 patch ...
 *   Applying sed/1.5.6 patch ...
 *   Applying as-needed/2.2.6 patch ...
 * Running elibtoolize in: binutils-2.28.1/bfd/
 *   Applying target-nm/2.4.2 patch ...
 *   Applying ppc64le/2.4.4 patch ...
 * Running elibtoolize in: binutils-2.28.1/binutils/
 *   Applying target-nm/2.4.2 patch ...
 *   Applying ppc64le/2.4.4 patch ...
 * Running elibtoolize in: binutils-2.28.1/etc/
 * Running elibtoolize in: binutils-2.28.1/gas/
 *   Applying target-nm/2.4.2 patch ...
 *   Applying ppc64le/2.4.4 patch ...
 * Running elibtoolize in: binutils-2.28.1/gold/
 * Running elibtoolize in: binutils-2.28.1/gprof/
 *   Applying target-nm/2.4.2 patch ...
 *   Applying ppc64le/2.4.4 patch ...
 * Running elibtoolize in: binutils-2.28.1/intl/
 * Running elibtoolize in: binutils-2.28.1/ld/
 *   Applying target-nm/2.4.2 patch ...
 *   Applying ppc64le/2.4.4 patch ...
 * Running elibtoolize in: binutils-2.28.1/libiberty/
 * Running elibtoolize in: binutils-2.28.1/opcodes/
 *   Applying target-nm/2.4.2 patch ...
 *   Applying ppc64le/2.4.4 patch ...
 * Running elibtoolize in: binutils-2.28.1/zlib/
 *   Applying target-nm/2.4.2 patch ...
 *   Applying ppc64le/2.4.4 patch ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/sys-devel/binutils-2.28.1/work/binutils-2.28.1 ...

 *  CATEGORY: sys-devel
 *    CBUILD: x86_64-pc-linux-gnu
 *     CHOST: x86_64-pc-linux-gnu
 *   CTARGET: x86_64-pc-linux-gnu
 *    CFLAGS: -march=native -O2
 *   LDFLAGS: -Wl,-O1 -Wl,--as-needed

./configure --enable-gold --enable-plugins --without-included-gettext --with-system-zlib --build=x86_64-pc-linux-gnu --enable-secureplt --prefix=/usr --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --datadir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.28.1 --infodir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.28.1/info --mandir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.28.1/man --bindir=/usr/x86_64-pc-linux-gnu/binutils-bin/2.28.1 --libdir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.28.1 --libexecdir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.28.1 --includedir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.28.1/include --enable-obsolete --enable-shared --enable-threads --enable-relro --enable-install-libiberty --disable-werror --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 2.28.1 p1.0 --disable-static --disable-gdb --disable-libdecnumber --disable-readline --disable-sim --without-stage1-ldflags
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking for C compiler default output file name...
configure: error: in `/var/tmp/portage/sys-devel/binutils-2.28.1/work/build':
configure: error: C compiler cannot create executables
See `config.log' for more details.
 * ERROR: sys-devel/binutils-2.28.1::gentoo failed (configure phase):
 *   (no error message)
 *
 * Call stack:
 *     ebuild.sh, line  115:  Called src_configure
 *   environment, line 2557:  Called toolchain-binutils_src_configure
 *   environment, line 3482:  Called die
 * The specific snippet of code:
 *       "${S}"/configure "${myconf[@]}" || die;
 *
 * If you need support, post the output of `emerge --info '=sys-devel/binutils-2.28.1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/binutils-2.28.1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-devel/binutils-2.28.1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-devel/binutils-2.28.1/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-devel/binutils-2.28.1/work/build'
 * S: '/var/tmp/portage/sys-devel/binutils-2.28.1/work/binutils-2.28.1'

>>> Failed to emerge sys-devel/binutils-2.28.1, Log file:

>>>  '/var/tmp/portage/sys-devel/binutils-2.28.1/temp/build.log'

 * Messages for package sys-devel/binutils-2.28.1:

 * ERROR: sys-devel/binutils-2.28.1::gentoo failed (configure phase):
 *   (no error message)
 *
 * Call stack:
 *     ebuild.sh, line  115:  Called src_configure
 *   environment, line 2557:  Called toolchain-binutils_src_configure
 *   environment, line 3482:  Called die
 * The specific snippet of code:
 *       "${S}"/configure "${myconf[@]}" || die;
 *
 * If you need support, post the output of `emerge --info '=sys-devel/binutils-2.28.1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/binutils-2.28.1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-devel/binutils-2.28.1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-devel/binutils-2.28.1/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-devel/binutils-2.28.1/work/build'
 * S: '/var/tmp/portage/sys-devel/binutils-2.28.1/work/binutils-2.28.1'




Code:
[ebuild  N    ] sys-devel/binutils-2.28.1  USE="cxx nls -multitarget -static-libs {-test} -vanilla"










Error messages found in config.log:

Code:
## ----------- ##
## Core tests. ##
## ----------- ##

configure:2297: checking build system type
configure:2311: result: x86_64-pc-linux-gnu
configure:2358: checking host system type
configure:2371: result: x86_64-pc-linux-gnu
configure:2391: checking target system type
configure:2404: result: x86_64-pc-linux-gnu
configure:2458: checking for a BSD-compatible install
configure:2526: result: /usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c
configure:2537: checking whether ln works
configure:2559: result: yes
configure:2563: checking whether ln -s works
configure:2567: result: yes
configure:2574: checking for a sed that does not truncate output
configure:2638: result: /bin/sed
configure:2647: checking for gawk
configure:2663: found /usr/bin/gawk
configure:2674: result: gawk
configure:4078: checking for x86_64-pc-linux-gnu-gcc
configure:4094: found /usr/bin/x86_64-pc-linux-gnu-gcc
configure:4105: result: x86_64-pc-linux-gnu-gcc
configure:4374: checking for C compiler version
configure:4383: x86_64-pc-linux-gnu-gcc --version >&5
x86_64-pc-linux-gnu-gcc (Gentoo 5.4.0-r3 p1.4, pie-0.6.5) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:4394: $? = 0
configure:4383: x86_64-pc-linux-gnu-gcc -v >&5
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0-r3 p1.4, pie-0.6.5' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer
Thread model: posix
gcc version 5.4.0 (Gentoo 5.4.0-r3 p1.4, pie-0.6.5)
configure:4394: $? = 0
configure:4383: x86_64-pc-linux-gnu-gcc -V >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-V'
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:4394: $? = 1
configure:4383: x86_64-pc-linux-gnu-gcc -qversion >&5
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-qversion'
x86_64-pc-linux-gnu-gcc: fatal error: no input files
compilation terminated.
configure:4394: $? = 1
configure:4414: checking for C compiler default output file name
configure:4436: x86_64-pc-linux-gnu-gcc -march=native -O2  -Wl,-O1 -Wl,--as-needed conftest.c  >&5
x86_64-pc-linux-gnu-gcc: error trying to exec 'as': execvp: No such file or directory
configure:4440: $? = 1
configure:4477: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:4483: error: in `/var/tmp/portage/sys-devel/binutils-2.28.1/work/build':
configure:4487: error: C compiler cannot create executables
See `config.log' for more details.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7200

PostPosted: Wed Nov 01, 2017 9:44 am    Post subject: Reply with quote

I just hate preserved-libs, it cause more trouble than solve.
What is good with preserved-libs is that it preserved libraries that are use by some packages, preventing these packages from been broken.
What is bad with preserved-libs is that it keep useless libraries in your system until any packages using them are gone. But until this is done, portage will complains about the useless libraries.

I think the first idea behind it was good (prevent packages from breaking), but someone didn't deep think about the result.
In gentoo early days, when no preserved-libs exists, packages were just broken, and users might have hard time fixing that.
It was nightmare when broken packages were critical for the system (gcc is one good example with mpfr)

But it was early days, and emerge have two cool things today that were lacking: revdep-rebuild and binary package.

I highly prefer my system that just break the package and do remove the old library.
It's healthy that a package is broken because the old library is gone, it first force to solve any package issue that cannot run with the newer version and stop using an old library (that could be buggy or have cve issue).

You can run revdep-rebuild -L oldlib.soname to have emerge rebuild packages that are using the old lib, just the same as preserved-libs except you have 0 complain from portage this time.

You can set FEATURES="-preserved-libs" to remove this useless and bugging feature and get back to old days handling, but with revdep-rebuild tool that will ease the job.
You can set FEATURES="buildpkg" to enable binary building of your package, allowing you to re-install that infamous old lib your package wants in a second to fix it's broken status if affect package was critical (if gcc is broken because of mpfr, you could reinstall binary package of mpfr and your old gcc that depends on it to get back in time and have a system that still can build ; upto you then to find a way to fix that, but with a working system). But that just for such a case of a critical tool, you will in real just never use binary because of that, but binaries of your package would solve you one day or another.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7200

PostPosted: Wed Nov 01, 2017 9:47 am    Post subject: Reply with quote

For your (now) issue, look at eselect binutils list and select the 2.28 to fix your symlinks and make them pointing to the newer tools (as is a binutil tools), and emerge is certainly complaining that as-2.25 is gone.

And if you didn't install binutils-2.28 prior removing older 2-25, you're in the case where binary package would had save your ass.
If you have done that, either use a livecd to get a working toolchain, or try seek a 2-28 binary and install it to have a working toolchain, or seek a 2-25 binary to restore your toolchain and upgrade to 2-28 with it.
Yeah, binutils is a critical tool for your toolchain, you should just never remove any, upgrade first and let emerge remove it after the upgrade.
Back to top
View user's profile Send private message
thurnax
Tux's lil' helper
Tux's lil' helper


Joined: 17 Apr 2014
Posts: 90

PostPosted: Wed Nov 01, 2017 10:33 am    Post subject: Reply with quote

binutils is now completely gone. "eselect binutils list" returns absolutely nothing, not even an error message.

I'm not sure what to do with a LiveCD let alone how one can get a working toolchain from it. I have searched through the Gentoo handbook for clues. Found none. I'm in the system right now, perhaps I could fetch a stage3 tarball and extract missing files from it?

'emerge -K binutils' doesn't work.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7200

PostPosted: Wed Nov 01, 2017 10:55 am    Post subject: Reply with quote

go with the livecd, mount your system in its /mnt/gentoo like when you prepare the chroot.
all you need to do is building the binary version of binutils that you could then re-use for yourself after.
which mean PKGDIR=/mnt/gentoo/usr/portage/packages quickpkg binutils
PKGDIR= will tell portage where to store the binary, so in your own disk and at a position where the package binary will be seek.
Then chroot and do emerge -pvk =binutils-version-from-the-livecd to check it will use it and install it
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44208
Location: 56N 3W

PostPosted: Wed Nov 01, 2017 12:31 pm    Post subject: Reply with quote

krinns method in the chroot requires that you can install binutils without binutils already installed.
I don't know if it works or not.

There is another way without the use of the chroot but its not reccomended until all else has failed.
Post back if you need it.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
thurnax
Tux's lil' helper
Tux's lil' helper


Joined: 17 Apr 2014
Posts: 90

PostPosted: Wed Nov 01, 2017 5:43 pm    Post subject: Reply with quote

It took me some thinking. I thought at first that I should mount the liveCD and then chroot into that and build the binaries from there. Then I booted from the LiveCD, compiled binutils there. It compiles in that environment without problems, but I cannot get the binaries to get stored in the chrooted environment.

Am I to understand that I have to change the PKGDIR= line in /etc/portage/make.conf to:

Code:
PKGDIR=/mnt/gentoo/usr/portage/packages quickpkg binutils
and not just
Code:
PKGDIR="/mnt/gentoo/usr/portage/packages"
?

Ok tried both. The former doesn't work but the latter builds the package. However, I cannot get emerge to install the binary in /mnt/gentoo when chrooted there. Neither "emerge -vk ..." nor "emerge -vK ..." work.

Ok, I found on this page. That the built in command quickpgk builds binary packages of already installed packages. That made "emerge -vK ..." work inside the chrooted environment. We'll see how things will go...

I think I restored the binutils package. But the screen mode is messed up, has something changed to VESA or something?
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7200

PostPosted: Wed Nov 01, 2017 6:39 pm    Post subject: Reply with quote

NeddySeagoon wrote:
krinns method in the chroot requires that you can install binutils without binutils already installed.

Possible, but in this case, while binutils is critic to compile something, it should had no use for emerge that use python, and because the package is binary, emerge should just not build anything but just extract files from the binary.
While i didn't test for real, i'm still confident it will works.

thurnax wrote:
Am I to understand that I have to change the PKGDIR= line in /etc/portage/make.conf to:

The idea is to take the already built binutils from the livecd, make a binary of it, and then use that binary for yourself.
Doing quickpkg binutils you create the binary
And doing it with PKDIR= set before the instruction override the environment (the livecd one) and set it like the command line you use, allowing on the fly change. And because default location for binaries in gentoo are /usr/portage/packages i change that directory to /mnt/gentoo/usr/portage/packages as it's the relative path to your own binaries directory.
Look:
Code:
>grep PKGDIR /etc/portage/make.conf
# PKGDIR is the location of binary packages that you can have created
#PKGDIR=${PORTDIR}/packages
>PKGDIR=/tmp/tmpbin quickpkg binutils
 * Building package for sys-devel/binutils-2.28-r2 ...                   [ ok ]

 * Packages now in '/tmp/tmpbin':
 * sys-devel/binutils-2.28-r2: 8.9M
>ls /tmp/tmpbin/sys-devel/
binutils-2.28-r2.tbz2


So with the command, it will install the binary in /mnt/gentoo/usr/portage/packages
But if you chroot, then that file will be relative to your own PKGDIR if you don't use any, which per default is /usr/portage/packages and that's where portage will look for it.
But if you then use PKG=/mnt/gentoo/usr/portage/packages you do it wrong because you have no /mnt/gentoo inside your chroot.
So, inside chroot, just use "emerge" alone, without PKGDIR, or if you really want use PKGDIR because your make.conf use a different PKG or to be certain you do it right inside the chroot then do PKGDIR=/usr/portage/packages emerge -Kpv =binutils-version_of_package

to take the sample upper
Code:

>PKGDIR=/badpath emerge -Kpv =binutils-2.28-r2
These are the packages that would be merged, in order:

Calculating dependencies... done!

emerge: there are no binary packages to satisfy "=binutils-2.28-r2".

>PKGDIR=/tmp/tmpdir emerge -Kpv =binutils-2.28-r2
These are the packages that would be merged, in order:

Calculating dependencies... done!
[binary   R    ] sys-devel/binutils-2.28-r2:2.28::gentoo  USE="cxx nls -multitar
Back to top
View user's profile Send private message
thurnax
Tux's lil' helper
Tux's lil' helper


Joined: 17 Apr 2014
Posts: 90

PostPosted: Thu Nov 02, 2017 10:23 am    Post subject: Reply with quote

Yes, I got it back and everything compiles again. I managed to figure it out after googling for "gentoo binary package" and found that doc page I mentioned in my prior post.

But when dealing with this update process and cleaning things out you run into issues. So when you manage to fix one issue, you have at the same time broken something else ...


Now something has turned weird with the vmware-tools. The most important functionality of vmware tools is that it adjusts the desktop screen resolution to the size of the window it is running in or to the native resolution when in full-screen mode. Now I have a small window in the middle of my monitor that I cannot change.


I don't know what that binutils package has done to accomplish this. Even GRUB is low-res now (the GRUB_GFXMODE=1680x1050 line is still there in the GRUB config). I used to have a high resolution mode when booting up but that is now completely gone. :(


I used to install vmware-tools manually through vmware's virtual CD-ROM, but have given up with later versions since they complain that '/usr/bin/gcc' is not a valid binary and no valid linux headers are found in '/usr/src/linux' even though I took steps to build headers... But now there is a 'vmware' repository in the layman/overlay so I emerged it as a package from there. Alas, that didn't resolve the issue with the screen resolution. I'm not even sure whether it installed properly as it returned the warning: "You should set VMWARE_GUEST in make.conf to specify which operating systems you need." I did set VMWARE_GUEST="linux" and even added the USE flag vmware_guest_linux but the warning remains and 'emerge --info' doesn't show the USE flag "vmware_guest_linux" in the information.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7200

PostPosted: Fri Nov 03, 2017 2:11 am    Post subject: Reply with quote

The right tool, the right function.
It also works for the forum, the right topic, the right help :)

While i'm aware of your new problem, i didn't came here for that, and have no idea about vm-ware trouble, and vm-ware specialist might not seen this thread, because it's a thread about preserved-libs.

I'm just trying to say: open a new thread, with the right topic, and you might attract vm-ware helpers, and so, help yourself.
Back to top
View user's profile Send private message
thurnax
Tux's lil' helper
Tux's lil' helper


Joined: 17 Apr 2014
Posts: 90

PostPosted: Sat Nov 04, 2017 1:42 pm    Post subject: Reply with quote

Ok will do, it's just that this problem is related to the revdep-rebuild and one problem leads to another...

I highly doubt that a vmware specialist is interested in Gentoo unfortunately. Ubuntu, SUSE, Red Hat and perhaps Debian yes, Gentoo and Arch no :(
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44208
Location: 56N 3W

PostPosted: Sat Nov 04, 2017 2:29 pm    Post subject: Reply with quote

thurnax,

A lot of virtualisation issues are common across hypervisors.
A new problem deserves a new topic anyway.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum