Dear guys and girls,

I have successfully bootstraped Gentoo Prefix on some old Fedora Core 3
machine on which I am only a normal user. I am very happy. Gentoo rocks!
Alt rocks! Prefix rocks!

Now I am locking my target on some AIX machines. But the problems come
up in an early stage.

First after STFW, I found I need to use prefix-launcher on
sf.net. QUESTION: is prefix-launcher an official part of gentoo-prefix?
I can see most recent svn ci's. why is it hosted on sf instead of
gentoo?

But prefix-launcher fail wildly when it's compiling gcc-4.2.4.

I was frustrated to do make clean && make install on prefix-launcher
again and again. Finally I realized I have to compile gcc-4.2.4 by
myself.

But there comes the linker problem:

There are always some unresolved symbol issue in stage 3 of
bootstrap. After another round of STFW, esp. on gcc bugzilla, I think it
is some path issue on AIX linker. ld just couldn't find the right
library to link against.

Any hints and ideas are appreciated.

I attach the latest command (cmd) and linking message (debug).

--
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

Hi Benda,

heroxbd@gmail.com wrote:
> Dear guys and girls,
>
> I have successfully bootstraped Gentoo Prefix on some old Fedora Core 3
> machine on which I am only a normal user. I am very happy. Gentoo rocks!
> Alt rocks! Prefix rocks!

Thank you!

> Now I am locking my target on some AIX machines. But the problems come
> up in an early stage.
>
> First after STFW, I found I need to use prefix-launcher on
> sf.net. QUESTION: is prefix-launcher an official part of gentoo-prefix?
> I can see most recent svn ci's. why is it hosted on sf instead of
> gentoo?

Well, it is not "official" part of Gentoo Prefix, but it is a
de-facto requirement to bootstrap on AIX and HP-UX (maybe others).
It _may_ work to bootstrap without prefix-launcher there,
but it is a lot harder than on Linux and Solaris fex.
The reason it is on sf is that the "prefix"-idea was born before
"Gentoo Prefix" as the implementation.

> But prefix-launcher fail wildly when it's compiling gcc-4.2.4.

This is interesting: I'm using prefix-launcher (checking out from svn,
not the release-tarball) on a weekly automated basis...

> I was frustrated to do make clean && make install on prefix-launcher
> again and again. Finally I realized I have to compile gcc-4.2.4 by
> myself.

Well, prefix-launcher itself does not support 'make clean',
just 'make install' (where 'make' has to be GNU-make).

> But there comes the linker problem:
>
> There are always some unresolved symbol issue in stage 3 of
> bootstrap. After another round of STFW, esp. on gcc bugzilla, I think it
> is some path issue on AIX linker. ld just couldn't find the right
> library to link against.
>
> Any hints and ideas are appreciated.
>
> I attach the latest command (cmd) and linking message (debug).

I'm going to look why/where these symbols are resolved from here...

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

Hey Micheal,

Michael Haubenwallner <haubi@gentoo.org> writes:

> Well, it is not "official" part of Gentoo Prefix, but it is a
> de-facto requirement to bootstrap on AIX and HP-UX (maybe others).
> It _may_ work to bootstrap without prefix-launcher there,
> but it is a lot harder than on Linux and Solaris fex.
> The reason it is on sf is that the "prefix"-idea was born before
> "Gentoo Prefix" as the implementation.

I see.

I have struggled through the gcc phase. I did very dirty hacks including
replacing failing steps with linking against hand-pointed libraries.

So now I have gcc-4.2.4 at hand.

Next comes the coreutils-6.9.

I did ./configure --prefix=$HOME/tools then make

,----
| gcc -std=gnu99 -I. -g -O2 -MT cycle-check.o -MD -MP -MF
| .deps/cycle-check.Tpo -c -o cycle-check.o cycle-check.c
| mv -f .deps/cycle-check.Tpo .deps/cycle-check.Po
| gcc -std=gnu99 -I. -g -O2 -MT dirchownmod.o -MD -MP -MF
| .deps/dirchownmod.Tpo -c -o dirchownmod.o dirchownmod.c
| mv -f .deps/dirchownmod.Tpo .deps/dirchownmod.Po
| gcc -std=gnu99 -I. -g -O2 -MT dirfd.o -MD -MP -MF .deps/dirfd.Tpo
| -c -o dirfd.o dirfd.c
| mv -f .deps/dirfd.Tpo .deps/dirfd.Pogcc -std=gnu99 -I. -g -O2 -MT
| dirname.o -MD -MP -MF .deps/dirname.Tpo -c -o dirname.o dirname.c
| mv -f .deps/dirname.Tpo .deps/dirname.Po
| gcc -std=gnu99 -I. -g -O2 -MT dup-safer.o -MD -MP -MF
| .deps/dup-safer.Tpo -c -o dup-safer.o dup-safer.c
| dup-safer.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
| before '.' token
| make[2]: *** [dup-safer.o] Error 1
| make[2]: Leaving directory `/home/k/benda/coreutils-6.9/lib'
| make[1]: *** [all] Error 2
| make[1]: Leaving directory `/home/k/benda/coreutils-6.9/lib'
| make: *** [all-recursive] Error 1
`----

the dup-safer.c file is very strange:

,----
| $ cat lib/dup-safer.c
| ccTvzRll.i.o : /tmp/ccTvzRll.i
`----

I never saw this kind of c program.

Given this box already have a very old version coreutils (in the age of
gcc-3.3) in /opt/freeware/bin (IBM shipped GNU tools?), I decided just
go ahead, ignoring the coreutils-6.9 failure.

so I make config coreutils_SUPPLY = EXTERNAL and proceeded.

Finally, prefix-launcher is done. (Hooray!)

then I executed eprefix-bootstrap.

But problems keeps emerging. (wel, I swear I did not $ emerge problems)

One very annoying problem is, the portage system keeps using /bin/sh
(which is a very very very ancient version of ksh of AIX) as the
building SHELL. A fair envoke of "/bin/sh <some long command with
long arguments can result in "Arg list too long" error, and booooom,
emerge exits.

I tried many times (set -xv in ebuild.sh, python -pdb with ebuild....)
and could not find a way to tell portage to use my favorite bash
compiled by prefix-launcher. (Dahhh)

So each time there is an error, I have to spot which step goes wrong and
open another shell (with modern bash of course) to execute the failed
step. It works, just using a good SHELL.

Hours of hours doing by hand. Now I am exhausted. I have to find a way
to tell portage to use bash, and get rid of the f***ingly old sh. I am a
normal user, I can't replace /bin/sh with the symlink to bash. (Dahhhh!)

Any hints or ideas?

Yours,
--
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

On 08-04-2010 20:40:02 +0900, heroxbd@gmail.com wrote:
> I tried many times (set -xv in ebuild.sh, python -pdb with ebuild....)
> and could not find a way to tell portage to use my favorite bash
> compiled by prefix-launcher. (Dahhh)
>
> So each time there is an error, I have to spot which step goes wrong and
> open another shell (with modern bash of course) to execute the failed
> step. It works, just using a good SHELL.
>
> Hours of hours doing by hand. Now I am exhausted. I have to find a way
> to tell portage to use bash, and get rid of the f***ingly old sh. I am a
> normal user, I can't replace /bin/sh with the symlink to bash. (Dahhhh!)

Actually, portage refuses to install itself without bash. Does
$EPREFIX/usr/lib/portage/bin/ebuild.sh really contain #!/bin/sh as
shebang?


--
Fabian Groffen
Gentoo on a different level

heroxbd@gmail.com wrote:
> I have struggled through the gcc phase. I did very dirty hacks including
> replacing failing steps with linking against hand-pointed libraries.
>
> So now I have gcc-4.2.4 at hand.
>
> Next comes the coreutils-6.9.

> the dup-safer.c file is very strange:
>
> ,----
> | $ cat lib/dup-safer.c
> | ccTvzRll.i.o : /tmp/ccTvzRll.i
> `----

Can't say why, but this obviously is not the correct content of lib/dup-safer.c

> One very annoying problem is, the portage system keeps using /bin/sh

Must admit I've added 'export CONFIG_SHELL=/some/bash' to my ~/.profile
long time ago - and actually forgot about it, so this didn't bite me again...

> Hours of hours doing by hand. Now I am exhausted. I have to find a way
> to tell portage to use bash, and get rid of the f***ingly old sh. I am a
> normal user, I can't replace /bin/sh with the symlink to bash. (Dahhhh!)
>
> Any hints or ideas?

It may help even for your initial gcc troubles to set CONFIG_SHELL prior
to any other operation, either building prefix-launcher or anything else.

Oh well, there's another thing to check first:
$ /usr/sbin/lsattr -EH -l sys0 | grep ncargs
ncargs 40 ARG/ENV list size in 4K byte blocks True

The default value of 6 (or even 4) usually is too small - we've set it
to 40 here, but this can be done by root only:
$ /usr/sbin/chdev -l sys0 -a ncargs=40

Although Sun for example does recommend a value of 16:
http://docs.sun.com/app/docs/doc/820-3530/gfxyz?a=view

Another question: Which version of gcc do you have already installed
and build prefix-launcher with?

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

heroxbd@gmail.com wrote:
> There are always some unresolved symbol issue in stage 3 of
> bootstrap. After another round of STFW, esp. on gcc bugzilla, I think it
> is some path issue on AIX linker. ld just couldn't find the right
> library to link against.

Quoting from your 'cmd' attachment:
> gcc ... -o cc1-dummy ...

Are you sure this is stage 3 in building gcc?
In stage 2 and above, it is not "gcc" being used, but something like
"/path/to/builddir/prev-gcc/xgcc" instead.

Quoting from your 'debug' attachment:
> (ld): i /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc.a
> (ld): i /opt/freeware/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc_eh.a

Your subject says AIX5.3, but your gcc-3.3.2 was built on AIX5.2.
This is a really bad idea.

Also, there is still /opt/freeware/ in library search path - this feels right
for stage 1 only, but not for stage 3.

Or do you have something like LIBPATH or LIBRARY_PATH set in your env?

> ld: 0711-317 ERROR: Undefined symbol: .__clzdi2
> .__clzdi2 [358] ER PR ../.././gcc/combine.c(libbackend.a[combine.o])
> 00004f04 .text R_RBR [2102] .extended_count
> 00006bc8 .text R_RBR [2262] <.force_to_mode>

Here I do have _clzdi2.o in builddir, being packed into libgcc.a
and thus available when linking cc1-dummy in stage 2 and above.

I'm doing the built with gcc-3.3.6 installed to /usr/local/, but combine.o
from stage1 does not refer to __clzdi2, while it does in stage2 and stage3.

> ld: 0711-317 ERROR: Undefined symbol: .libintl_dgettext
> .libintl_dgettext [96] ER PR ../.././libcpp/files.c(../libcpp/libcpp.a[files.o])
> 00001228 .text R_RBR [929] <.report_missing_guard>

Could you eventually send me (offlist) your complete build log file for gcc,
located within prefix-launcher in buildroot/log/gcc.build.*.log

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

Dear Michael,

Michael Haubenwallner <haubi@gentoo.org> writes:

> Must admit I've added 'export CONFIG_SHELL=/some/bash' to my ~/.profile
> long time ago - and actually forgot about it, so this didn't bite me again...

Does the build shell in portage respect $HOME/.profile? I have set
'export CONFIG_SHELL=/some/bash'. When I do ./configure manually, it
would be bash (seen in ps). But if I emerge, all ./configure are called
with /bin/sh (seen in ps).

Are you sure this really works?

Yours,
--
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

heroxbd@gmail.com wrote:
> Dear Michael,
>
> Michael Haubenwallner <haubi@gentoo.org> writes:
>
>> Must admit I've added 'export CONFIG_SHELL=/some/bash' to my ~/.profile
>> long time ago - and actually forgot about it, so this didn't bite me again...
>
> Does the build shell in portage respect $HOME/.profile? I have set
> 'export CONFIG_SHELL=/some/bash'. When I do ./configure manually, it
> would be bash (seen in ps). But if I emerge, all ./configure are called
> with /bin/sh (seen in ps).

Just committed a portage patch to actually use $CONFIG_SHELL when calling configure's.

In usr/portage/prefix/aix/profile.bashrc you can find CONFIG_SHELL=$BASH,
so an ebuild calling configure (via econf or not) should have CONFIG_SHELL set.

> Are you sure this really works?

While it was enough for long time to just do:
$ export CONFIG_SHELL=/path/to/bash
$ ./configure
recently it seems necessary to do:
$ export CONFIG_SHELL=/path/to/bash
$ ${CONFIG_SHELL} ./configure

So I didn't encounter problems when doing this:
$ export CONFIG_SHELL=/path/to/bash # done by profile.bashrc
$ ${CONFIG_SHELL} ./configure # done by portage now

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

Hi Michael,

Michael Haubenwallner <haubi@gentoo.org> writes:

>> Are you sure this really works?
>
> While it was enough for long time to just do:
> $ export CONFIG_SHELL=/path/to/bash
> $ ./configure
> recently it seems necessary to do:
> $ export CONFIG_SHELL=/path/to/bash
> $ ${CONFIG_SHELL} ./configure
>
> So I didn't encounter problems when doing this:
> $ export CONFIG_SHELL=/path/to/bash # done by profile.bashrc
> $ ${CONFIG_SHELL} ./configure # done by portage now

I just did not know modifying profile.bashrc is the way to affect the
portage building shell. Now I understand. Thank you for your
explanation.

Cheers,
--
XU Benda
Research Center for Neutrino Science
Tohoku University
JAPAN

http://www.awa.tohoku.ac.jp/~benda

heroxbd@gmail.com wrote:
>> So I didn't encounter problems when doing this:
>> $ export CONFIG_SHELL=/path/to/bash # done by profile.bashrc
>> $ ${CONFIG_SHELL} ./configure # done by portage now
>
> I just did not know modifying profile.bashrc is the way to affect the
> portage building shell. Now I understand. Thank you for your
> explanation.

Well, you shouldn't need to actually _modify_ profile.bashrc,
as CONFIG_SHELL is _already_ set there[1]. However, portage
didn't explicitly run configure via CONFIG_SHELL before [2].

[1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/prefix/aix/profile.bashrc?view=markup
[2] http://overlays.gentoo.org/proj/alt/changeset/57670

/haubi/
--
Michael Haubenwallner
Gentoo on a different level