From: "Bradley D. LaRonde" <brad@ltc.com>
To: <linux-mips@oss.sgi.com>
Subject: cross-mipsel-linux-ld --prefix library path
Date: Mon, 6 Aug 2001 23:56:36 -0400 [thread overview]
Message-ID: <074001c11ef4$fdbd7530$3501010a@ltc.com> (raw)
In-Reply-To: 20010806083942.A16047@lucon.org
When I build and install cross-binutils (on Debian 2.2) like this:
tar -xzf binutils-2.11.2.tar.gz
mkdir mipsel-binutils
cd mipsel-binutils
../binutils-2.11.2/configure --target=mipsel-linux \
--prefix=/usr/mipsel-linux
make
make install
it seems the resulting mipsel-linux-ld wants to look in:
/usr/mipsel-linux/mipsel-linux/lib
for crt1.o, crti.o, libc.*, etc.
However, a cross-built glibc like:
tar -xzf glibc-2.2.3
cd glibc-2.2.3
patch -p1 -i../elf32-tradlittlemips.diff
tar -xzf ../glibc-linuxthreads-2.2.3.tar.gz
cd ..
mkdir mipsel-glibc
cd mipsel-glibc
../glibc-2.2.3/configure --build=i686-linux \
--host=mipsel-linux --prefix=/usr/mipsel-linux \
--with-headers=/usr/mipsel-linux/include --enable-add-ons
make
make install
puts it's stuff in:
/usr/mipsel-linux/lib/
not:
/usr/mipsel-linux/mipsel-linux/lib/
My first suspicion is that --prefix=/usr/mipsel-linux for binutils
is naive, but --prefix=/usr looks like a disaster (would overwrite
native stuff like libbfd.la for example, whatever that is).
Another odd thing is that binutils installs:
/usr/mipsel-linux/bin/mipsel-linux-ld
and an identical copy at:
/usr/mipsel-linux/mipsel-linux/bin/ld
This seems like a Clue. If fact, the whole
/usr/mipsel-linux/mipsel-linux thing seems off to me. Only, being
only an RTN (Reluctant Toolchain Neophyte), that's about as far as
I've gotten with it.
Analysis (of the software, not me)? :-)
Regards,
Brad
WARNING: multiple messages have this Message-ID (diff)
From: "Bradley D. LaRonde" <brad@ltc.com>
To: linux-mips@oss.sgi.com
Subject: cross-mipsel-linux-ld --prefix library path
Date: Mon, 6 Aug 2001 23:56:36 -0400 [thread overview]
Message-ID: <074001c11ef4$fdbd7530$3501010a@ltc.com> (raw)
Message-ID: <20010807035636.PZI-4uPbjPz6fMvJ391WraH5fF8_-BQxOkDf2GAhVRw@z> (raw)
In-Reply-To: 20010806083942.A16047@lucon.org
When I build and install cross-binutils (on Debian 2.2) like this:
tar -xzf binutils-2.11.2.tar.gz
mkdir mipsel-binutils
cd mipsel-binutils
../binutils-2.11.2/configure --target=mipsel-linux \
--prefix=/usr/mipsel-linux
make
make install
it seems the resulting mipsel-linux-ld wants to look in:
/usr/mipsel-linux/mipsel-linux/lib
for crt1.o, crti.o, libc.*, etc.
However, a cross-built glibc like:
tar -xzf glibc-2.2.3
cd glibc-2.2.3
patch -p1 -i../elf32-tradlittlemips.diff
tar -xzf ../glibc-linuxthreads-2.2.3.tar.gz
cd ..
mkdir mipsel-glibc
cd mipsel-glibc
../glibc-2.2.3/configure --build=i686-linux \
--host=mipsel-linux --prefix=/usr/mipsel-linux \
--with-headers=/usr/mipsel-linux/include --enable-add-ons
make
make install
puts it's stuff in:
/usr/mipsel-linux/lib/
not:
/usr/mipsel-linux/mipsel-linux/lib/
My first suspicion is that --prefix=/usr/mipsel-linux for binutils
is naive, but --prefix=/usr looks like a disaster (would overwrite
native stuff like libbfd.la for example, whatever that is).
Another odd thing is that binutils installs:
/usr/mipsel-linux/bin/mipsel-linux-ld
and an identical copy at:
/usr/mipsel-linux/mipsel-linux/bin/ld
This seems like a Clue. If fact, the whole
/usr/mipsel-linux/mipsel-linux thing seems off to me. Only, being
only an RTN (Reluctant Toolchain Neophyte), that's about as far as
I've gotten with it.
Analysis (of the software, not me)? :-)
Regards,
Brad
next prev parent reply other threads:[~2001-08-07 3:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-05 16:48 Changing WCHAR_TYPE from "long int" to "int"? H . J . Lu
2001-08-05 17:06 ` Gabriel Dos Reis
2001-08-06 9:59 ` Ralf Baechle
2001-08-06 10:10 ` Andreas Jaeger
2001-08-06 14:27 ` Eric Christopher
2001-08-06 16:28 ` Ralf Baechle
2001-08-07 11:52 ` MIPS ABI (was: Changing WCHAR_TYPE from "long int" to "int"?) Paul Kasper
2001-08-07 12:31 ` Ralf Baechle
2001-08-07 16:07 ` H . J . Lu
2001-08-06 16:20 ` Changing WCHAR_TYPE from "long int" to "int"? Ralf Baechle
2001-08-06 16:29 ` H . J . Lu
2001-08-06 17:04 ` Gabriel Dos_Reis
2001-08-06 17:25 ` Ralf Baechle
2001-08-06 14:12 ` Eric Christopher
2001-08-06 14:40 ` Thiemo Seufer
2001-08-06 14:41 ` Eric Christopher
2001-08-06 15:29 ` H . J . Lu
2001-08-06 15:33 ` Eric Christopher
2001-08-06 15:39 ` H . J . Lu
2001-08-06 16:23 ` Eric Christopher
2001-08-07 3:56 ` Bradley D. LaRonde [this message]
2001-08-07 3:56 ` cross-mipsel-linux-ld --prefix library path Bradley D. LaRonde
2001-08-07 7:40 ` Geert Uytterhoeven
2001-08-07 14:10 ` Bradley D. LaRonde
2001-08-07 14:10 ` Bradley D. LaRonde
2001-08-07 14:10 ` Maciej W. Rozycki
2001-08-07 14:14 ` Bradley D. LaRonde
2001-08-07 14:14 ` Bradley D. LaRonde
2001-08-07 14:36 ` Maciej W. Rozycki
2001-08-07 14:42 ` Steve Langasek
2001-08-07 14:42 ` Steve Langasek
2001-08-07 15:25 ` Bradley D. LaRonde
2001-08-07 15:25 ` Bradley D. LaRonde
2001-08-07 19:27 ` Steve Langasek
2001-08-07 19:27 ` Steve Langasek
2001-08-06 23:49 ` Changing WCHAR_TYPE from "long int" to "int"? Ralf Baechle
2001-08-06 15:22 ` H . J . Lu
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='074001c11ef4$fdbd7530$3501010a@ltc.com' \
--to=brad@ltc.com \
--cc=linux-mips@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.