| 1 |
commit: de8d4332d2ffbe1f627a2e97d582650c80c87cd1 |
| 2 |
Author: W. Trevor King <wking <AT> tremily <DOT> us> |
| 3 |
AuthorDate: Fri Apr 12 18:13:57 2013 +0000 |
| 4 |
Commit: Brian Dolbec <dolsen <AT> gentoo <DOT> org> |
| 5 |
CommitDate: Thu Feb 26 19:15:21 2015 +0000 |
| 6 |
URL: http://sources.gentoo.org/gitweb/?p=proj/catalyst.git;a=commit;h=de8d4332 |
| 7 |
|
| 8 |
doc/catalyst-config.5.txt: Document linking issues with binary packages |
| 9 |
|
| 10 |
This gives users a heads up explaining why they might see linking |
| 11 |
errors when pkgcache is enabled. I first saw this when I build a |
| 12 |
stage1 without update_seed. Because my seed stage3 linked against |
| 13 |
libmpc.so.2, some of my stage1 files linked against the older mpc. |
| 14 |
However, the mpc-1.0.1 built for the stage1 installed libmpc.so.3. |
| 15 |
When I tried to use this stage1 to build a stage2, it died with: |
| 16 |
|
| 17 |
/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1: |
| 18 |
error while loading shared libraries: libmpc.so.2: |
| 19 |
cannot open shared object file: No such file or directory |
| 20 |
|
| 21 |
To fix this, I enabled update_seed, but binary packages built during |
| 22 |
my first pass were used to populate the stage1, so even though I'd |
| 23 |
updated the seed stage3 toolchain, I still had a stage1 with cc1 |
| 24 |
linked against libmpc.so.2. |
| 25 |
|
| 26 |
After clearing the binary package cache, I got a stage1 *built* with |
| 27 |
the updated seed stage3, which gave a cc1 linked against libmpc.so.3 |
| 28 |
(hurray!). |
| 29 |
|
| 30 |
This commit adds a warning in the pkgcache documentation that should |
| 31 |
help people understand what might be going wrong if they see similar |
| 32 |
linking errors. For more details, see the thread following |
| 33 |
http://thread.gmane.org/gmane.linux.gentoo.catalyst/2137/focus=2193 |
| 34 |
|
| 35 |
--- |
| 36 |
doc/catalyst-config.5.txt | 44 +++++++++++++++++++++++++++++++++++++++++++- |
| 37 |
1 file changed, 43 insertions(+), 1 deletion(-) |
| 38 |
|
| 39 |
diff --git a/doc/catalyst-config.5.txt b/doc/catalyst-config.5.txt |
| 40 |
index 27bc0bb..63a015f 100644 |
| 41 |
--- a/doc/catalyst-config.5.txt |
| 42 |
+++ b/doc/catalyst-config.5.txt |
| 43 |
@@ -126,7 +126,8 @@ build dies during `livecd-stage2`. |
| 44 |
pkgcache:: |
| 45 |
Enable `--usepkg` and `--buildpkg` for most *emerge(1)* runs. This is |
| 46 |
useful if your build dies prematurely. However, you may experience |
| 47 |
-linking problems. |
| 48 |
+linking problems. See the *BINARY PACKAGE DEPENDENCIES* section for |
| 49 |
+details. |
| 50 |
|
| 51 |
seedcache:: |
| 52 |
Use the build output of a previous target if it exists to speed up the |
| 53 |
@@ -174,6 +175,47 @@ ripemd256, ripemd320, sha1, sha224, sha256, sha384, sha512, snefru128, |
| 54 |
snefru256, tiger, tiger128, tiger160, whirlpool. |
| 55 |
|
| 56 |
|
| 57 |
+BINARY PACKAGE DEPENDENCIES |
| 58 |
+--------------------------- |
| 59 |
+This section is only important if you are using binary packages to |
| 60 |
+build your stages (by enabling the `pkgcache` option and restarting |
| 61 |
+incomplete builds). |
| 62 |
+ |
| 63 |
+Before EAPI-5 introduced ABI sub-slots, the build-time compatibility |
| 64 |
+of packages was not recorded. This leads to problems such as binary |
| 65 |
+GCC packages built against mpc-0.8.2 (which installs libmpc.so.2) |
| 66 |
+being installed on systems that only have mpc-1.0.1 (which installs |
| 67 |
+libmpc.so.3), resulting in: |
| 68 |
+ |
| 69 |
+--------------------------------- |
| 70 |
+/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1: |
| 71 |
+ error while loading shared libraries: libmpc.so.2: |
| 72 |
+ cannot open shared object file: No such file or directory |
| 73 |
+--------------------------------- |
| 74 |
+ |
| 75 |
+As long as there are packages in your stage that don't use ABI |
| 76 |
+sub-slots, you may experience errors like this due to untracked ABI |
| 77 |
+missmatches in binary packages. Packages generated by catalyst builds |
| 78 |
+are currently namespaced: |
| 79 |
+ |
| 80 |
+--------------------------------- |
| 81 |
+.../packages/<rel_type>/<target>-<subarch>-<version_stamp>/Packages |
| 82 |
+--------------------------------- |
| 83 |
+ |
| 84 |
+so running into these out-of-date packages is unlikely. You may run |
| 85 |
+into problems if: |
| 86 |
+ |
| 87 |
+* you enable `update_seed` in your stage1 spec after a previous run |
| 88 |
+ which generated packages linking against out-of-date seed libraries |
| 89 |
+ or |
| 90 |
+* you update your snapshot and an untracked ABI dependency is bumped |
| 91 |
+ without a similar bump in the dependent package. |
| 92 |
+ |
| 93 |
+without also bumping any of the package namespace variables in your |
| 94 |
+spec. If you do make such a change, it's a good idea to clear the |
| 95 |
+package cache in question and rebuild the packages from scratch. |
| 96 |
+ |
| 97 |
+ |
| 98 |
FILES |
| 99 |
----- |
| 100 |
An example configuration file can be found at |
Archives