Bugzilla Bug 193364

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 an attachment (id=131761) [details]
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. ***

*** Bug 195933 has been marked as a duplicate of this bug. ***

ive added a `find|touch` to toolchain-binutils.eclass