From: Paul Bame <bame@endor.fc.hp.com>
To: parisc-linux@thepuffingroup.com
Subject: [parisc-linux] building a glibc-based tool chain
Date: Thu, 06 Apr 2000 12:05:57 -0600 [thread overview]
Message-ID: <E12dGfF-00012e-00@endor.fc.hp.com> (raw)
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
next reply other threads:[~2000-04-06 18:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-06 18:05 Paul Bame [this message]
2000-04-09 6:06 ` [parisc-linux] building a glibc-based tool chain Bdale Garbee
2000-04-09 7:27 ` Bdale Garbee
2000-04-09 16:17 ` David Huggins-Daines
2000-04-09 16:56 ` Bdale Garbee
2000-04-11 15:50 ` Paul Bame
2000-04-13 23:38 ` Paul Bame
2000-04-14 21:48 ` David Huggins-Daines
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E12dGfF-00012e-00@endor.fc.hp.com \
--to=bame@endor.fc.hp.com \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox