66449 2004-10-05 11:58 0000 gettext-$NEWVERSION libs and programs links against the old installed gettext-$OLDVERSION LIBS. 2004-11-04 19:10:43 0000 1 1 1 Unclassified Gentoo Linux Development unspecified All Linux RESOLVED FIXED P2 normal --- 66951 1 motaboy@gentoo.org base-system@gentoo.org aaron@cs.tu-berlin.de axxo@gentoo.org beber@meleeweb.net blackcrow@libero.it centic@gentoo.org dave@technopagan.org edge@smtn.stavropol.ru glowinthedark@accesscomm.ca hegjon@gmail.com heretic@clanhk.org hey_neken@mundurat.net ivo.welch@yale.edu jsaker@americanrelay.com lisa@gentoo.org mark@vicarageclose.com mmessmore@gmail.com nathan@nightsys.net notellin@speakeasy.net polynomial-c@gentoo.org sandman@173rd-airborne.com stefan@konink.de yumi@ziet.zhitomir.ua motaboy@gentoo.org 2004-10-05 11:58:47 0000 I upgraded to gettext-0.14.1 but it's program are linked against gettext-0.12.1-r1 (the previously installed) For example: xgettext: error while loading shared libraries: libgettextlib-0.12.1.so: cannot open shared object file: No such file or directory So I had to reemerge again it, so it linked against the same right libs and it works. Then to test it I emerged gettext-0.12.1 and again: xgettext: error while loading shared libraries: libgettextlib-0.14.1.so: cannot open shared object file: No such file or directory I can always reproduce it, so let me know what you need. Reproducible: Always Steps to Reproduce: Actual Results: Portage 2.0.51_rc7 (default-x86-2004.0, gcc-3.4.2, glibc-2.3.4.20040808-r0, 2.6.9-rc1-mm2 i686) ================================================================= System uname: 2.6.9-rc1-mm2 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.6.1 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-mtune=i686 -O2" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mtune=i686 -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache collision-protect confcache distlocks keeptemp keepwork sandbox" GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/bmg-main /usr/local/bmg-gnome-current" SYNC="rsync://rsync1.it.gentoo.org/gentoo-portage" USE="3dnow X acl acpi acpi4linux alsa apm arts atm audiofile avi berkdb bitmap-fonts bluetooth breakme cdr crypt cscope cups curl cvs dga doc dv dvd dvdr encode evo evolution fbcon ffmpeg flac foomaticdb freetype gdbm gif gimpprint gmp gpm gtk2 gtkhtml hal imlib ipv6 irmc java jpeg kakasi kde kerberos krb4 ldap libg++ libgda libwww mad mikmod mmx motif moznocompose moznoirc moznomail mozsvg mpeg ncurses nls nptl oggvorbis opengl opie oss pam pda pdflib perl png ppds python qt quicktime readline ruby samba sdl slang smime spell sse ssl svga tcpd tiff truetype usb wifi wmf x86xine xml xml2 xmms xprint xv xvid yv12 zlib" vapier@gentoo.org 2004-10-05 21:30:35 0000 run revdep-rebuild, the gettext authors seem to do this on purpose :/ motaboy@gentoo.org 2004-10-06 01:32:17 0000 Of course, I ran revdep-rebuild, but I don't understand the author purpose. If it links against the oldgettext, then the old shouldn't be removed at least... It will break any ebuild that need gettext, so I think that if this can't be fixed at least the user should be informed about this situation. or no? vapier@gentoo.org 2004-10-06 05:55:31 0000 very true ... i added a warning to the ebuild motaboy@gentoo.org 2004-10-06 06:18:20 0000 Thanks! motaboy@gentoo.org 2004-10-06 06:31:32 0000 mmm. Sorry again if I'm pedant... :D I don't know if the warning reported is correct, because the problem is inside gettext itself. The problem is that gettext links to the old gettext installed libraries instead its just compiled one. The other ebuilds reports error because during the build is called the xgettext (or other) program present in gettext that is badly linked. So only gettext need to be rebuilt. Also looking in the gentoo's CVS I've found a commit from sejo 88 minutes ago: Revision 1.6 - (download), view (text) (markup) (annotate) - [select for diffs] Wed Oct 6 11:47:08 2004 UTC (88 minutes, 21 seconds ago) by sejo Branch: MAIN Changes since 1.5: +2 -2 lines Diff to previous 1.5 back to unstable untill the linking error is fixed Is this related to this problem? axxo@gentoo.org 2004-10-06 07:36:59 0000 *** Bug 66527 has been marked as a duplicate of this bug. *** axxo@gentoo.org 2004-10-06 07:46:19 0000 warning is wrong packages don't need to be rebuilds, its gettext itself that needs to be rebuild after just installed it ?? vapier@gentoo.org 2004-10-06 08:12:04 0000 for some reason i thought 'xgettext' was provided by another package ... sounds like the linking process is broken in gettext, i'll look motaboy@gentoo.org 2004-10-06 08:18:00 0000 I think that I've found the solution: the problem is generated by the use of --without-included-gettext introduced from gettext-0.12.1-r1 to fix bug #40162 If I install gettext-0.12.1 instead of r1, it uses --with-included-gettext and the programs like xgettext (in gettext) are linked correctly. THEN SOME instructions on how to test my assertions and reproduce it: 1) install gettext-0.14.1 2) install gettext-0.12.1-r1 (that uises --without-included-gettext) 3) run xgettext, you'll get the link error because it searches for the libraries from 0.14.1 4) Reinstall gettext-0.14.1 5) install gettext-0.12.1 (that uses --with-included-gettext) 6) run xgettext, it'll work because is linked to the right libraries from the current version and not from the already installed version. motaboy@gentoo.org 2004-10-06 08:50:39 0000 mmmm. I was wrong, the problem isn't caused by --without-included-gettext but from --disable-shared that was removed from 0.12.1-r1. motaboy@gentoo.org 2004-10-06 09:35:15 0000 but of course tt's not a solution restoring it (--disabled-shared) because it'll give a lot of problems with other packages... like I'm having now with media-sound/normalize lv@gentoo.org 2004-10-06 16:04:28 0000 *** Bug 66473 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-10-06 22:09:35 0000 *** Bug 66589 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-10-06 22:10:06 0000 0.14.1 is now masked nlissne@linux01.gwdg.de 2004-10-07 09:25:54 0000 downgrading to 0.12.1-r1 (caused by the hardmask of 0.14) reproduced this problem. As the headers of 0.14 were installed when it compiled 0.12.1 it linked against the 0.14 version - recompiling solved this - so it looks like compiling 0.14 twice helps, too nlissne@linux01.gwdg.de 2004-10-07 09:44:06 0000 yes, that works - so it's the ebuild, not the gettext version that is broken - simply emerge gettext again links against the correct header, however revdep-rebuild would have done the same, so the solution is already given in the ebuild-info ;) Please, fix the ebuild to use the correct headers instead of hardmasking a working version of gettext. polynomial-c@gentoo.org 2004-10-07 09:59:12 0000 Hi, I can confirm that emerging gettext-0.14.1 twice links gettext against the correct libs. Poly motaboy@gentoo.org 2004-10-07 10:15:03 0000 Sorry, But the fact that recompiling fixes it was already explained by me. The problem is to found why it links against the installed library and not the compiled one. Probably you are mixing the headers sense with the libraries. axxo@gentoo.org 2004-10-07 13:10:49 0000 *** Bug 66685 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-10-07 15:58:36 0000 *** Bug 66637 has been marked as a duplicate of this bug. *** notellin@speakeasy.net 2004-10-07 19:17:27 0000 Um guys ... It's great that gettext-0.14.1 is now masked. However, binutils-2.15.92.0.2 apparently depends on gettext-0.14.1 and won't build with gettext-0.12... Perhaps the new version of binutils should be masked as well? And anything else which depends on gettext-0.14.1? :-) ... error while loading chared libraries: libgettextlib-0.14.1.so: cannot open shared object: ... vapier@gentoo.org 2004-10-07 19:24:08 0000 no it doesnt (or i doubt it ... :x), rebuild gettext a few times until it works again, and then build binutils cyberspacecomputers@msn.com 2004-10-07 19:58:13 0000 Spanky just so you know this is only a case if your updating from one version to another if this is a clean system build everything works fine .... if your bootstraping the system use package.unmask to use the latest wich does not break compatibility for all you other users sorry about your luck build a better system :p vapier@gentoo.org 2004-10-07 20:03:32 0000 yes, we know it's an upgrade path bug, the problem is the large majority of users are going to use that path and not bootstrap with 0.14.1 :P until the upgrade path is clean, gettext-0.14.1 will stay masked mmessmore@gmail.com 2004-10-07 21:38:06 0000 binutils-2.15.92.0.2 is trying to link to libgettextlib-0.14.1.so. Until a package that provides that file is unmasked, binutils-2.15.92.0.2 should be masked as well. This seems (at least to my amateur eyes) to be a different issue from the one this bug was filed about. I'm still at gettext-0.12.1-r1. I did not install 0.14.1 and roll back to the older ebuild, nor do anything out of the oridinary. This machine is running pretty much, straight up ~x86. But new binutils is trying to link to 0.14.1. So basically right now anyone running ~x86 would have to add binutils-2.15.92.0.2 (god, thats a rediculously long version string) to their package.mask file in order to be able to `emerge --update' world merrily or add gettext-0.14.1 to their package.unmask file and deal with the issues in that package that were deemed mask-worthy. I don't feel like fooling with it and am just adding the binutils package to my package.mask until this gets straightened out. vapier@gentoo.org 2004-10-07 21:46:31 0000 > binutils-2.15.92.0.2 should be masked as well. This seems (at least to my > amateur eyes) to be a different issue from the one this bug was filed about. it isnt ... the error you posted showed the gettext program trying to run and failing; re-emerge gettext in other words > I did not install 0.14.1 and roll back to the older ebuild you sure about that ? might want to review emerge.log in /var/log/ > So basically right now anyone running ~x86 would have to add > binutils-2.15.92.0.2 to their package.mask file in order to be able no, see above do whatever you like on your box to make it happy, it doesnt change the facts about gettext/binutils notellin@speakeasy.net 2004-10-08 04:31:06 0000 Spanky is correct. emerging gettext-12... twice solves thes problem with binutils. Despite being counter-intuitive to this non-programmer, it works. So who am I to argue with success? I've done this on two different systems now. But it's still weird as heck. vapier@gentoo.org 2004-10-09 16:38:09 0000 *** Bug 66862 has been marked as a duplicate of this bug. *** axxo@gentoo.org 2004-10-10 07:37:07 0000 *** Bug 66981 has been marked as a duplicate of this bug. *** foser@gentoo.org 2004-10-10 09:13:50 0000 *** Bug 66939 has been marked as a duplicate of this bug. *** lv@gentoo.org 2004-10-11 00:26:35 0000 *** Bug 66951 has been marked as a duplicate of this bug. *** lv@gentoo.org 2004-10-12 03:55:12 0000 *** Bug 67119 has been marked as a duplicate of this bug. *** swtaylor@gentoo.org 2004-10-14 14:47:13 0000 *** Bug 67268 has been marked as a duplicate of this bug. *** lv@gentoo.org 2004-10-16 06:19:09 0000 *** Bug 67613 has been marked as a duplicate of this bug. *** ciaran.mccreesh@googlemail.com 2004-10-17 10:04:12 0000 *** Bug 67465 has been marked as a duplicate of this bug. *** swegener@gentoo.org 2004-10-19 13:12:14 0000 *** Bug 68191 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-10-22 05:33:35 0000 *** Bug 68487 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-10-27 11:46:24 0000 *** Bug 69146 has been marked as a duplicate of this bug. *** krinn@chez.com 2004-10-27 20:55:09 0000 I really think it's a bug related to gettext (not really gentoo) Library link is to libgettextlib-0.x.x.so but a symlink from libgettextlib.so exist, so wrong linking? But anyway here's a quick solve: >emerge gettext >xgettext xgettext: error while loading shared libraries: libgettextlib-0.12.1.so: cannot open shared object file: No such file or directory >ln -s /usr/lib/libgettextlib-0.14.1.so /usr/lib/libgettextlib-0.12.1.so >ln -s /usr/lib/libgettextsrc-0.14.1.so /usr/lib/libgettextsrc-0.12.1.so >xgettext xgettext: no input file given Try `xgettext --help' for more information. i have just try with xgettext, try with others programs to be sure, but i just think the link is to the "old 0.12.1" lib but must use the new lib, so it's safe to symlink the new to old ones... Ah and also! downgrading from 0.14.1 to 0.12.1 and you will get the same problem (with the same solve of course) krinn@chez.com 2004-10-27 21:56:28 0000 Created an attachment (id=42744) new ebuild with patch diff gettext-0.14.1-r1.ebuild gettext-0.14.1.ebuild 14c14 < KEYWORDS="~x86" --- > KEYWORDS="-*" 89,91d88 < # to close bug #66449 < ln -s ${D}/usr/lib/libgettextlib-0.14.1.so ${D}/usr/lib/libgettextlib-0.12.1.so < ln -s ${D}/usr/lib/libgettextsrc-0.14.1.so ${D}/usr/lib/libgettextsrc-0.12.1.so ivo.welch@yale.edu 2004-10-28 06:00:52 0000 should this become the standard? emerge search gettext on amd64 still tells me that 0.12.1-r2 is the current version, which of course blocks some other installs. mholzer@gentoo.org 2004-10-28 08:32:40 0000 don't use #ln -s man 5 ebuild and see the dosym command krinn@chez.com 2004-10-28 17:04:52 0000 Well, test the workaround if it's ok (seems ok here), just do a good ebuild to help stop that bug... see impact of masking it http://bugs.gentoo.org/show_bug.cgi?id=69326 vapier@gentoo.org 2004-10-28 17:10:10 0000 *** Bug 69326 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-10-28 17:10:40 0000 just so you guys know, that isnt an acceptable 'fix' krinn@chez.com 2004-10-29 08:17:05 0000 dosym /usr/lib/libgettextlib-0.14.1.so /usr/lib/libgettextlib-0.12.1.so dosym /usr/lib/libgettextsrc-0.14.1.so /usr/lib/libgettextsrc-0.12.1.so Change to that ? Ah and why it isn't acceptable ? The fix just create a sym link to old libs, if the symlinks isn't need, then you have only a symlink for nothing... I think it far more acceptable than asking everyone to compile it twice! Sure compiling twice is easy to do, but not if gettext is emerge from an "emerge world"... And if i look at gettext-0.14.1.ebuild, a symlink to correct a bug is something that should be acceptable... >cat gettext-0.14.1.ebuild | grep 43 dosym msgfmt /usr/bin/gmsgfmt #43435 Anyway a "clean" and conventional fix should be force gettext to link against libgettextlib.so and libgettextsrc.so (cause they are present in both the 0.14 and 0.12 and are symlinks to correct libs). But this will not correct the problem if someone downgrade to 0.12.1 because the 0.12.1 ebuild is also bug and have the same problem So if you mask the 0.14 cause of that bug, you should also mask 0.12.1-r* for the same reason. Note that this bug was introduce in the 0.12.1-r1 ebuild (i don't have it anymore after rsync), the 0.12.1 itself was working fine... So i suppose the fix introduce to the 0.12.1-r1 to correct bug #40162 is the problem and i think it's that part (comment #6) "Also should be built with shared libs for it to have preloadable_libintl.so. Anyhow, added -r1 of gettext and commited your ebuild with dep on gettext if nls in USE." So: after removing to gettext the --disable-share, this gives that bug we are speaking about Now you have choices: - do the symlink as i say - put --disable-share but might reopen but #40162 now i hope you understand not only 0.14.1 is affect but all ebuild for gettext that didn't include the --disable-share in it... (i think it's 0.12.1-r1, r2 and 0.14.1) vapier@gentoo.org 2004-10-29 08:31:44 0000 actually, i'm going with option (3) fix libtool like i said, the symlinks arent going to be added to portage comparing it to the gmsgfmt symlinks is completely unrelated and not applicable krinn@chez.com 2004-10-29 08:37:06 0000 maybe re-enable --disable-share and see if a better fix could be found for #40162 ? krinn@chez.com 2004-10-29 08:44:27 0000 actually your option 3 seems the best motaboy@gentoo.org 2004-10-29 08:46:18 0000 Like I've said in comment #11, reanabling --disable-share gave me problems with some ebuilds. vapier@gentoo.org 2004-10-31 01:53:44 0000 if someone feels so inclined to break their system, `emerge sync` and try out gettext-0.14.1 ... to see if you have the version i want you to try, the unpack phase should apply a bunch of patches to ltmain.sh motaboy@gentoo.org 2004-10-31 03:06:23 0000 Thanks vapier, I had the gettext-0.12.1-r2 installed, and upgrading to your new version didn't get any linking problem. xgettext and all the other program seems to works weel. Probably this need also some other testing emerging programs that uses gettext but I'm fiducious :D . vapier@gentoo.org 2004-11-04 19:10:43 0000 ok, seems to be resolved now ... moved 0.14.1 to unstable ;) 42744 2004-10-27 21:56 0000 new ebuild with patch gettext-0.14.1-r1.ebuild application/octet-stream IyBDb3B5cmlnaHQgMTk5OS0yMDA0IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6IC92YXIvY3Zzcm9vdC9nZW50b28teDg2L3N5cy1kZXZlbC9nZXR0ZXh0L2dldHRleHQtMC4x NC4xLmVidWlsZCx2IDEuMTAgMjAwNC8xMC8wNyAyMzo1MTo0NiB2YXBpZXIgRXhwICQKCmluaGVy aXQgZXV0aWxzIGdudWNvbmZpZyBnY2MgbW9ubwoKREVTQ1JJUFRJT049IkdOVSBsb2NhbGUgdXRp bGl0aWVzIgpIT01FUEFHRT0iaHR0cDovL3d3dy5nbnUub3JnL3NvZnR3YXJlL2dldHRleHQvZ2V0 dGV4dC5odG1sIgpTUkNfVVJJPSJtaXJyb3I6Ly9nbnUvJHtQTn0vJHtQfS50YXIuZ3oKCW1pcnJv cjovL2dlbnRvby8ke1B9LWJvb3RzdHJhcC5wYXRjaC5iejIiCgpMSUNFTlNFPSJHUEwtMiIKU0xP VD0iMCIKS0VZV09SRFM9In54ODYiCklVU0U9ImJvb3RzdHJhcCBlbWFjcyBubHMiCgpERVBFTkQ9 InZpcnR1YWwvbGliYyIKCnNyY191bnBhY2soKSB7Cgl1bnBhY2sgJHtBfQoJY2QgJHtTfQoJdXNl IGJvb3RzdHJhcCAmJiBlcGF0Y2ggJHtXT1JLRElSfS8ke1B9LWJvb3RzdHJhcC5wYXRjaAoJaWYg dXNlIHNwYXJjOyB0aGVuCgkJZXBhdGNoICR7RklMRVNESVJ9LyR7UH0td2l0aG91dF9qYXZhLnBh dGNoCgkJZXBhdGNoICR7RklMRVNESVJ9LyR7UH0tbm8tamF2YS10ZXN0cy5wYXRjaAoJZmkKCWdu dWNvbmZpZ191cGRhdGUKfQoKc3JjX2NvbXBpbGUoKSB7CgkjIENvbXBhcSBKYXZhIHNlZ2ZhdWx0 cyB0cnlpbmcgdG8gYnVpbGQgZ2V0dGV4dCBzdHVmZiwgYW5kIHRoZXJlJ3MKCSMgbm8gZ29vZCB3 YXkgdG8gdGVsbCBnZXR0ZXh0IHRvIHJlZnJhaW4gZnJvbSBidWlsZGluZyB0aGUgamF2YQoJIyBz dHVmZiwgc28uLi4gcmVtb3ZlIGNvbXBhcS1qZGsvanJlIGZyb20gdGhlIFBBVEgKCWlmIHVzZSBh bHBoYSAmJiBbWyAkSkFWQUMgPT0gKmNvbXBhcSogXV07IHRoZW4KCQlQQVRIPSQoZWNobyAiOiR7 UEFUSH0iIHwgc2VkICdzfDovb3B0L2NvbXBhcS1qW146XSp8fGc7IHMvXjovLycpCgkJdW5zZXQg SkFWQV9IT01FIENMQVNTUEFUSCBKREtfSE9NRSBKQVZBQwoJZmkKCgkjIFdoZW4gdXBkYXRpbmcg aW4gc3BhcmMgd2l0aCBqYXZhIHRoZSBqdm0gc2VnZmF1bHRzCgl1c2Ugc3BhcmMgJiYgbXljb25m PSIke215Y29uZn0gLS13aXRob3V0LWphdmEiCgl1c2UgcHBjLW1hY29zICYmIG15Y29uZj0iJHtt eWNvbmZ9IC0tZW5hYmxlLW5scyIKCgkjIEJ1aWxkIHdpdGggLS13aXRob3V0LWluY2x1ZGVkLWdl dHRleHQgKHdpbGwgdXNlIHRoYXQgb2YgZ2xpYmMpLCBhcyB3ZQoJIyBuZWVkIHByZWxvYWRhYmxl X2xpYmludGwuc28gZm9yIG5ldyBoZWxwMm1hbiwgYnVnICM0MDE2Mi4KCSMgQWxzbyBub3RlIHRo YXQgaXQgb25seSBnZXRzIGJ1aWxkIHdpdGggVVNFPW5scyAuLi4KCSMgTGFzdGx5LCB3ZSBuZWVk IHRvIGJ1aWxkIHdpdGhvdXQgLS1kaXNhYmxlLXNoYXJlZCAuLi4KCUNYWD0kKGdjYy1nZXRDQykg XAoJCWVjb25mIFwKCQktLXdpdGhvdXQtaW5jbHVkZWQtZ2V0dGV4dCBcCgkJJCh1c2VfZW5hYmxl IG5scykgXAoJCSR7bXljb25mfSBcCgkJfHwgZGllCgoJZW1ha2UgfHwgZGllCn0KCnNyY19pbnN0 YWxsKCkgewoJZWluc3RhbGwgXAoJCWxpc3BkaXI9JHtEfS91c3Ivc2hhcmUvZW1hY3Mvc2l0ZS1s aXNwIFwKCQlkb2NkaXI9JHtEfS91c3Ivc2hhcmUvZG9jLyR7UEZ9L2h0bWwgXAoJCXx8IGRpZQoJ ZG9zeW0gbXNnZm10IC91c3IvYmluL2dtc2dmbXQgIzQzNDM1CgoJZXhlb3B0cyAtbTA3NTUKCWV4 ZWludG8gL3Vzci9iaW4KCWRvZXhlIGdldHRleHQtdG9vbHMvbWlzYy9nZXR0ZXh0aXplIHx8IGRp ZSAiZG9leGUiCgoJIyBHbGliYyBpbmNsdWRlcyBnZXR0ZXh0OyB0aGlzIGlzbid0IG5lZWRlZCBh bnltb3JlCiMJcm0gLXJmICR7RH0vdXNyL2luY2x1ZGUKIwlybSAtcmYgJHtEfS91c3IvbGliL2xp Yioue2Esc299CgoJIyBBZ2FpbiwgaW5zdGFsbGVkIGJ5IGdsaWJjCglybSAtcmYgJHtEfS91c3Iv c2hhcmUvbG9jYWxlL2xvY2FsZS5hbGlhcwoKCSMgL3Vzci9saWIvY2hhcnNldC5hbGlhcyBpcyBw cm92aWRlZCBieSBNYWMgT1MgWAoJKCB1c2UgbWFjb3MgfHwgdXNlIHBwYy1tYWNvcyApICYmIHJt IC1mICR7RH0vdXNyL2xpYi9jaGFyc2V0LmFsaWFzCgoJaWYgWyAtZCAke0R9L3Vzci9kb2MvZ2V0 dGV4dCBdCgl0aGVuCgkJbXYgJHtEfS91c3IvZG9jL2dldHRleHQgJHtEfS91c3Ivc2hhcmUvZG9j LyR7UEZ9L2h0bWwKCQlybSAtcmYgJHtEfS91c3IvZG9jCglmaQoKCSMgUmVtb3ZlIGVtYWNzIHNp dGUtbGlzcCBzdHVmZiBpZiAnZW1hY3MnIGlzIG5vdCBpbiBVU0UKCWlmICEgdXNlIGVtYWNzCgl0 aGVuCgkJcm0gLXJmICR7RH0vdXNyL3NoYXJlL2VtYWNzCglmaQoJIyB0byBjbG9zZSBidWcgIzY2 NDQ5CglsbiAtcyAke0R9L3Vzci9saWIvbGliZ2V0dGV4dGxpYi0wLjE0LjEuc28gJHtEfS91c3Iv bGliL2xpYmdldHRleHRsaWItMC4xMi4xLnNvCglsbiAtcyAke0R9L3Vzci9saWIvbGliZ2V0dGV4 dHNyYy0wLjE0LjEuc28gJHtEfS91c3IvbGliL2xpYmdldHRleHRzcmMtMC4xMi4xLnNvCgoJZG9k b2MgQVVUSE9SUyBCVUdTIENoYW5nZUxvZyBESVNDTEFJTSBORVdTIFJFQURNRSogVEhBTktTIFRP RE8KfQoKcGtnX3Bvc3RpbnN0KCkgewoJZXdhcm4gIkFueSBwYWNrYWdlIHRoYXQgbGlua2VkIGFn YWluc3QgdGhlIHByZXZpb3VzIHZlcnNpb24iCglld2FybiAib2YgZ2V0dGV4dCB3aWxsIGhhdmUg dG8gYmUgcmVidWlsdC4iCglld2FybiAiUGxlYXNlICdlbWVyZ2UgZ2VudG9vbGtpdCcgYW5kIHJ1 biAncmV2ZGVwLXJlYnVpbGQnIgp9Cg==