I'm not sure why in code listing 1.9 it explicitly states to emerge binutils 2.16 instead of the latest. But you need binutils >2.16 (ie. 2.18) in order to properly install coreutils 6.91 in code listing 1.14. If you don't have the proper version of binutils then coreutils will fail with something like: /home/jolexa/portage/solaris-9/usr/lib/gcc/sparc-sun-solaris2.9/4.2.0/crt1.o:(.plt+0x0): multiple definition of `_PROCEDURE_LINKAGE_TABLE_' /usr/ccs/lib/libgen.so:(.plt+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [[] Error 1 make[2]: Leaving directory `/home/jolexa/portage/solaris-9/var/tmp/portage/sys-apps/coreutils-6.9-r1/work/coreutils-6.9/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/jolexa/portage/solaris-9/var/tmp/portage/sys-apps/coreutils-6.9-r1/work/coreutils-6.9/src' make: *** [all-recursive] Error 1 A quick search of "_PROCEDURE_LINKAGE_TABLE_" led me to this link: http://www.mail-archive.com/gentoo-alt@lists.gentoo.org/msg02702.html which gave me the idea to try to update binutils. Apparently there is a bug in older versions that was fixed upstream. I ran into this bug on solaris 9 and solaris 10 SPARC. Let me know if you need any more information. Workaround: code listing 1.14: emerge -1av --nodeps binutils && emerge -1 --nodeps coreutils (verify that a new version of binutils is being emerged) OR change code listing 1.9 to just emerge the latest binutils (not sure what effect this will have) Verified that this will work with binutils 2.18*
I meant coreutils 6.9-r1. opps
Created attachment 131761 [details, diff] solaris.coreutils.patch Are you able to emerge coreutils-6.9-r1 on sparc-sun-solaris2.9 without any patches? I have to use the attached patch due to the missing "iswblank".
Please ignore my previous comments about binutils. I *think* my workaround works properly on Solaris 10 SPARC but I cannot remember anymore. Stefan's patch works - it should be added to the prefix overlay. maybe to the global tree? I'll leave that suggestion for someone that knows. Thanks!
(In reply to comment #0) > I'm not sure why in code listing 1.9 it explicitly states to emerge binutils > 2.16 instead of the latest. Reason is that >binutils-2.16* won't merge because of texinfo not merged yet. This maybe is a bug in >=binutils-2.17, and the workaround is to pass MAKEINFO=: to 'make' (or to 'emake' in the ebuild). Additionally, it requires 'flex' to be available. (In reply to comment #3) > Please ignore my previous comments about binutils. I *think* my workaround > works properly on Solaris 10 SPARC but I cannot remember anymore. > > Stefan's patch works - it should be added to the prefix overlay. maybe to the > global tree? I'll leave that suggestion for someone that knows. So you need both >binutils-2.16 and this patch I assume ?
patches should be applied unconditionally, shouldn't they?
(In reply to comment #5) > patches should be applied unconditionally, shouldn't they? There are several conditional patches in the (prefix) tree depending on the architecture, e.g. in app-misc/mc or dev-libs/glib.
(In reply to comment #4) > Reason is that >binutils-2.16* won't merge because of texinfo not merged yet. > This maybe is a bug in >=binutils-2.17, and the workaround is to pass > MAKEINFO=: > to 'make' (or to 'emake' in the ebuild). > > Additionally, it requires 'flex' to be available. texinfo can be bootstrapped with scripts/bootstrap-prefix.sh since r8782. flex can be emerged before binutils, it is even described in the Solaris 10 instructions (http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml). > So you need both >binutils-2.16 and this patch I assume ? The patch does not depend on the binutils version.
Fixed in r9968.
binutils-2.18.50.0.1 now successfully builds if makeinfo is unavailable. This should drop the requirement to bootstrap =sys-devel/binutils-2.16*.
From toolchain-binutils.eclass: # only build info pages if we user wants them, and if # we have makeinfo (may not exist when we bootstrap) if ! has noinfo ${FEATURES} ; then if type -p makeinfo > /dev/null ; then make info || die "make info failed" fi fi It makes me wonder why this code isn't triggered, and now almost replicated in the ebuild?
Problem is that >=binutils-2.17 needs makeinfo also for target 'all', not 'info' only.
point being here that this doesn't sound like a prefix only bug. @toolchain: recent binutils seems to require makeinfo, at least this is not a dependency, but I guess eventually this results in problems during bootstrapping on normal Gentoo as well?
recent releases of binutils accidentally had issues which caused makeinfo to execute when it should not have been i can add some calls to `touch` or something to remedy the issue
keeping us in the loop so we can undo our "hack" once this is fixed and synced from the main tree.
should be fixed in binutils-2.18-r1 now
(In reply to comment #15) > should be fixed in binutils-2.18-r1 now Doesn't work. Maybe you wanted to touch bfd/doc/bfd.info ? Have digged deeper into it now: bfd/elf.c is a prerequisite for bfd/doc/bfd.info: bfd/doc/bfd.info depends on bfd/doc/elf.texi depends on bfd/elf.c In vanilla sources, bfd/elf.c already is newer than bfd/doc/elf.texi. In gentoo-patches (binutils-2.18-patches-1.4), bfd/elf.c as well as bfd/format.c are patched, thus bfd/doc/format.texi is out of date too: bfd/doc/bfd.info depends on bfd/doc/format.texi depends on bfd/format.c So after patching, those three files need to be touched (for version 1.4 of binutils-2.18-patches): bfd/doc/elf.texi bfd/doc/format.texi bfd/doc/bfd.info It does not help to touch bfd/doc/bfd.info only, because bfd/doc/elf.texi and bfd/doc/format.texi are still out of date and get rebuilt, thus bfd/doc/bfd.info becomes out of date again. But then, if some info is patched in bfd/*.c, this wouldn't be compiled into bfd/doc/bfd.info as expected when makeinfo is available and 'noinfo' is not in FEATURES, as bfd/doc/bfd.info is already seen as up to date. One way could be to set MAKEINFO=true during 'emake all', as this does not actually build the bfd.info, but also not fail. Another way could be to patch out dependencies like "all: info" from Makefile.{am,in}, so that info really gets built with 'emake info' only, much like http://www.mail-archive.com/gentoo-alt@lists.gentoo.org/msg02506.html (or do that for Makefile.am with eautoreconf)
yeah, i swapped the files that need to get touched i'm trying to avoid patching code here ... that way i can move this to the common eclass ... can you try this: cd "${S}" touch bfd/doc/bfd.texinfo find . -name '*.info' -o -name '*.texi' -print0 | xargs -0 touch -r bfd/doc/bfd.texinfo
(In reply to comment #17) > find . -name '*.info' -o -name '*.texi' -print0 | xargs -0 touch -r > bfd/doc/bfd.texinfo It works when done with parenthesis: find . '(' -name '*.info' -o -name '*.texi' ')' -print0 | xargs -0 touch -r bfd/doc/bfd.texinfo But now, '*.info' is "up-to-date" (for make), and eventually subsequent 'emake info' becomes useless except for binutils < 2.17. So I still prefer doing 'emake all MAKEINFO=true' (and 'emake install MAKEINFO=true') in case of missing makeinfo.
*** Bug 195933 has been marked as a duplicate of this bug. ***
ive added a `find|touch` to toolchain-binutils.eclass
reworked it a bit more: http://sources.gentoo.org/eclass/toolchain-binutils.eclass?r1=1.129&r2=1.130
*** Bug 232616 has been marked as a duplicate of this bug. ***
