[parisc-linux] building a glibc-based tool chain

[parisc-linux] building a glibc-based tool chain

[Paul Bame]

Well it still doesn't work, but here are some UGLY HACKS I use to
get a tool chain built using our glibc, which only works on x86 I think.
There are many many failure modes which these steps avoid, or so I hope.
Lots of this is probably my misunderstanding of the glibc/gcc relationship.

First grab binutils and build it as usual.  I used

    .../binutils/configure --target=hppa1.1-linux --disable-nls \
	--prefix=/opt/palinux
    make
    make install

DO NOT allow the default --prefix to be used or you'll be SCREWED later
when you try to build gcc.

Fix your $PATH before going further:

    PATH=/opt/palinux/bin:$PATH

Now the nasty one.  Grab glibc and configure it:
    !! DO NOT allow the default --prefix to be used or you'll be SCREWED
    !! later when you try to build gcc.  If by chance you do an install
    !! into /usr/local you'll have to remove those files before gcc will
    !! build.

    .../glibc/configure --target=hppa1.1-linux --disable-nls \
	--prefix=/opt/palinux --disable-shared --disable-sanity-checks
    make

This will fail with undefined references.  Do:
    ls > nss/makedb
    make

This should complete.  This is pretty creepy but...

    for n in *
    do
	touch $n/stubs
    done

    make install

This will fail, but gets far enough to be useful.

Now in the top-level makefile in the real glibc source tree, remove
the dependency like this diff shows (otherwise the manual/ subdir build
will prevent success).

    diff -r1.1 Makefile
    142c142
    < $(inst_includedir)/gnu/stubs.h: subdir_install
    ---
    > $(inst_includedir)/gnu/stubs.h: 

Then:

    make /your/install/directory/include/gnu/stubs.h

Now remove the #ifdef __USE_UNIX98 and the matching #endif  /* Unix98 */
from /your/install/directory/include/unistd.h around line 238

Time for gcc

    .../gcc/configure --target=hppa1.1-linux --disable-nls --prefix=/opt/palinux

    make
    make install

For some unknown reason, this new hppa1.1-linux-gcc doesn't look in
/opt/palinux/include for headers, thus a quick hack:

    mv /opt/palinux/lib/gcc*/*/*/include/* /opt/palinux/include
    rmdir /opt/palinux/lib/gcc*/*/*/include/
    ln -s /opt/palinux/include /opt/palinux/lib/gcc*/*/*/include/

It might be better to use a different --prefix when configuring glibc
so as to have these header files installed where gcc expects to find them.

At this point I was able to compile but not link.  For some reason gcc
doesn't look in /opt/paliux/lib for crt1.o and friends.  When I
added crt0.o and libc by hand, the link failed with a meaningless error.

	-P

Re: [parisc-linux] building a glibc-based tool chain

[Bdale Garbee]

In article <E12dGfF-00012e-00@endor.fc.hp.com> you wrote:

> Well it still doesn't work, but here are some UGLY HACKS I use to
> get a tool chain built using our glibc, which only works on x86 I think.

Well, I was tired of working on my taxes, so I sat down to see what I could 
figure out.  

Attached below is my "Notebook" entry so far for today.  The keys were 
getting limits.h from the kernel tree into the target tree before the gcc 
build, and adding a couple of new options "--with-headers" and "--with-libs" 
to the gcc build.

Using a trivial hello world program in bdale.c, with what I've done, I get:

bdale@chunks:~/puffin/user-space-test-code: hppa1.1-linux-gcc -o bdale bdale.c
/opt/palinux/bin/../lib/gcc-lib/hppa1.1-linux/2.9-hppa-991112/../../../../hppa1.
1-linux/bin/ld: cannot open crtbegin.o: No such file or directory
collect2: ld returned 1 exit status
bdale@chunks:~/puffin/user-space-test-code:

Looking at the gcc source tree, crtbegin.asm is in gcc/config/alpha... on my
Debian box, I see:

bdale@chunks:~/puffin/gcc: find /usr/lib -name crt\*
/usr/lib/gcc-lib/i386-linux/2.95.2/crtbegin.o
/usr/lib/gcc-lib/i386-linux/2.95.2/crtbeginS.o
/usr/lib/gcc-lib/i386-linux/2.95.2/crtend.o
/usr/lib/gcc-lib/i386-linux/2.95.2/crtendS.o
/usr/lib/crt1.o
/usr/lib/crti.o
/usr/lib/crtn.o
bdale@chunks:~/puffin/gcc: 

We have the crt[1in].o in /opt/palinux/lib, but not crtbegin*.  I'm off to
see if I can figure that out now.

Bdale



2000.04.08
- give glibc a shot, using Paul's notes as a starting point, and a different
  prefix (so I don't mess up what I already have)

        mkdir binutils-glibc-build
        cd binutils-glibc-build
                ../binutils/configure --target=hppa1.1-linux --disable-nls \
                        --prefix=/opt/palinux
                make -j4
                sudo make install
        export PATH=/opt/palinux/bin:$PATH

        mkdir glibc-build
        cd glibc-build
                ../glibc/configure --target=hppa1.1-linux --disable-nls \
                  --prefix=/opt/palinux --disable-shared --disable-sanity-checks
                # note - using -j on the following make breaks the build
                make
                ls > nss/makedb
                make
                for n in *
                do
                        touch $n/stubs
                done
                sudo make install


  Now in the top-level makefile in the real glibc source tree, remove
  the dependency like this diff shows (otherwise the manual/ subdir build
  will prevent success).

    diff -r1.1 Makefile
    142c142
    < $(inst_includedir)/gnu/stubs.h: subdir_install
    ---
    > $(inst_includedir)/gnu/stubs.h:  

                sudo make /opt/palinux/include/gnu/stubs.h

  Now remove the #ifdef __USE_UNIX98 and the matching #endif  /* Unix98 */
  from /your/install/directory/include/unistd.h around line 238

        mkdir gcc-glibc-build
        cd gcc-glibc-build
                ../gcc/configure --target=hppa1.1-linux --disable-nls \
                        --prefix=/opt/palinux
                make -j4
                sudo make install

        sudo mv /opt/palinux/lib/gcc*/*/*/include/* /opt/palinux/include
        sudo rmdir /opt/palinux/lib/gcc*/*/*/include/
        sudo ln -s /opt/palinux/include \
                /opt/palinux/lib/gcc-lib/hppa1.1-linux/2.9-hppa-991112/include

                        sort of works, but same problems Paul had...

- try again, after trolling around http://gcc.gnu.org/onlinedocs/

        sudo rm -r /opt/palinux
        cd binutils-glibc-build
                sudo make install
        cd glibc-build
                sudo make install
                        - fails on the texinfo thing at the end, ignoring
        sudo vi /opt/palinux/include/unistd.h           (as above)
        (cd linux-2.3/include ; tar cf - linux/limits.h) | \
                (cd /opt/palinux/include ; sudo tar xvf -)
        cd gcc-glibc-build
                sudo rm -r *
                sudo ../gcc/configure --target=hppa1.1-linux --disable-nls \
                        --prefix=/opt/palinux \
                        --with-headers=/opt/palinux/include \
                        --with-libs=/opt/palinux/lib
                sudo make -j4
                sudo make install

Re: [parisc-linux] building a glibc-based tool chain

[Bdale Garbee]

In article <20000409060602.269491E9D6@rover.gag.com> you wrote:

> We have the crt[1in].o in /opt/palinux/lib, but not crtbegin*.  I'm off to
> see if I can figure that out now.

So, crtbegin/crtend are related to constructors and destructors for C++.  I
see where they get defined as part of extra_parts in the gcc build for various
architectures, but I confess to not understanding how they are being included
in my builds... 

If I run the compiler with -nostdlib and explicitly specify things, ld seg
faults.  See below.

With my extra options to the gcc builds cleaning up some of the manual goo
Paul was doing, and putting limits.h in place making the gcc build finish
cleanly, I feel like I've made some progress.  However, since I don't have any
idea why ld is seg faulting and have heard this isn't the first time that's
been tripped over, and since I don't see offhand how to get gcc to leave
out crtbegin any other way right now, I think I'm stuck.

Hmmm.  The "cannot size stub section" might correlate with Paul's ugly hack
making stub files?  Is this just garbage in -> garbage out?  Hmmm.

Bdale


bdale@chunks:~/puffin/user-space-test-code: hppa1.1-linux-gcc -nostdlib -o bdale /opt/palinux/lib/crt1.o bdale.c -lc -lgcc
collect2: ld terminated with signal 11 [Segmentation fault]
/opt/palinux/bin/../lib/gcc-lib/hppa1.1-linux/2.9-hppa-991112/../../../../hppa1.1-linux/bin/ld: can not size stub section: Bad value
bdale@chunks:~/puffin/user-space-test-code: 

Re: [parisc-linux] building a glibc-based tool chain

[David Huggins-Daines]

Bdale Garbee <bdale@gag.com> writes:

> In article <20000409060602.269491E9D6@rover.gag.com> you wrote:
> 
> > We have the crt[1in].o in /opt/palinux/lib, but not crtbegin*.  I'm off to
> > see if I can figure that out now.
> 
> So, crtbegin/crtend are related to constructors and destructors for C++.  I
> see where they get defined as part of extra_parts in the gcc build for various
> architectures, but I confess to not understanding how they are being included
> in my builds... 

They aren't always needed.  I suspect they may be related to whether
you compile code as position-independent or not, as the spec file on
i386 seems to indicate that they get linked in if you link with
-shared:

    16  *endfile:
    17  %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s

    28  *startfile:
    29  %{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s}                   %
    29  {!p:%{profile:gcrt1.o%s}                         %{!profile:crt1.o%s}}}}
    29      crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}

On Alpha (actually 64-bit RISC architectures in general, I think - for
rather intuitive reasons related to the size of instructions vs. the
size of pointers :) all code is position-independent, which is
probably why they're part of the standard runtime environment there.

So, this is probably another side effect of gcc and binutils assuming
that PA-RISC ELF targets are always 64-bit targets.  However I'm not
up on the details of Sammy's ELF32 ABI ...

Needless to say we won't be compiling any C++ programs for a little
while at least (can we remove dselect from the dpkg sources? please?
pretty please? :)  So, you could probably just edit them out of your
spec file manually for the time being.

-- 
David Huggins-Daines, Senior Linux Consultant, Linuxcare, Inc.
613.562.1239 desk, 613.223.0225 mobile
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] building a glibc-based tool chain

[Bdale Garbee]

In article <87em8fjlkm.fsf@tarwebok.thepuffingroup.com> you wrote:

> So, this is probably another side effect of gcc and binutils assuming
> that PA-RISC ELF targets are always 64-bit targets.  However I'm not
> up on the details of Sammy's ELF32 ABI ...

Aha.

> Needless to say we won't be compiling any C++ programs for a little
> while at least (can we remove dselect from the dpkg sources? please?
> pretty please? :)

Yes, in fact.  I chatted with Wichert (Debian Project Leader and one of the
current dpkg maintainers) the other night about how to bootstrap dpkg, and
there are now options that assist the process by skipping the dselect build
and the documentation build, both of which have *very* deep dependency chains.
On the other hand, I've been using Debian so long that dselect (with the apt
method, of course!) is a highly productive tool to me...  :-)  

> So, you could probably just edit them out of your spec file manually for 
> the time being.

I hadn't thought of that.  I'll try it in a bit.  Family obligations this
morning and the last regular-season Avalanche hockey game this afternoon...

Oh, and one more set of observations from last night, that I got too tired to
send off properly before I gave up and went to bed:

If you build glibc ala Paul, install it, build gcc and install it, then
build glibc again *pristine*, it builds completely and installs.  I gather
we've got a circular dependency between gcc and glibc builds.  I wasn't overly
surprised by this, but it's sort of rude after building cross compilation
environments using newlib.  So, once there is a bootstrapped glibc in the 
target tree, and gcc has been built, go back and undo the hacks (except the 
Unix98 one, which is still needed) and glibc builds and installs cleanly!

Bdale

Re: [parisc-linux] building a glibc-based tool chain

[Paul Bame]

= > So, crtbegin/crtend are related to constructors and destructors for C++.  I

I've been editing them out of the spec file by hand, but I suspect that
configure --disable-shared and setting the gcc configure languages list
to dis-include C++ might work too.  (If the lang list only had C in it,
the build might be faster too)

Another thing which is handy is to 'cd gcc; ln -s ../binutils .'
After this, the configure/make/make-install inside the gcc directory
properly handles binutils, so you don't have to do it separately and
it solves some of the installation problems I had before.

The linker problem is always where I end up stuck.  I tried mangling
the vmlinux.lds to link my hello world and that didn't work either,
but I'm NO linker expert.  FYI I added an assert() (it's in CVS) which
catches the linker segfault (binutils/bfd/elf32something) if anyone
wants to become a linker expert and figure it out :-)

	-P

Re: [parisc-linux] building a glibc-based tool chain

[Paul Bame]

Ok, using my prior instructions you'll get a 'glibc' containing
x86 object files!  crt1.o is one of those, and is probably why the
linker segfaults.

Although this is still naive, a better glibc config command is:

.../configure  \
    --prefix=/opt/palinux/lib/gcc-lib/hppa1.1-linux/2.9-hppa-991112  \
    --disable-nls  \
    --disable-sanity-checks  \
    --disable-shared  \
    --host=hppa1.1-linux  \
    --target=hppa1.1-linux  \
    --build=i386-linux  \
    --with-headers=/opt/puffin/include  \
    --without-nls  \
    --disable-profile

Currently this is dying in the glibc build but that will probably get
fixed tomorrow.

	-P

Re: [parisc-linux] building a glibc-based tool chain

[David Huggins-Daines]

Paul Bame <bame@endor.fc.hp.com> writes:

> Ok, using my prior instructions you'll get a 'glibc' containing
> x86 object files!  crt1.o is one of those, and is probably why the
> linker segfaults.

Yup, it wouldn't surprise me, since the Alpha linker also does this
when you try to link i386 object files with it.  Go binutils go!

(BTW: if you're using the aboot ISO9660 code for PALO, be forewarned
that there are some bad bugs in it that I've recently fixed - 0.7pre3
has the updates)

-- 
David Huggins-Daines, Senior Linux Consultant, Linuxcare, Inc.
613.562.1239 desk, 613.223.0225 mobile
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.