Changing WCHAR_TYPE from "long int" to "int"?

Changing WCHAR_TYPE from "long int" to "int"?

[H . J . Lu]

I am working with Eric to clean up the Linux/mips configuration in
gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They
are the same on Linux/mips. There won't be any run-time problems. I am
wondering if there are any compatibility problems at the compile time
at the source and binary level. For one thing, __WCHAR_TYPE__ will be
changed from "long int" to "int". The only thing I can think of is
the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one
I am working on will be the first gcc 3.x for Linux/mips. So there
shouldn't be any problems. Am I right?


H.J.

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Gabriel Dos Reis]

"H . J . Lu" <hjl@lucon.org> writes:

| changed from "long int" to "int". The only thing I can think of is
| the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one
| I am working on will be the first gcc 3.x for Linux/mips. So there
| shouldn't be any problems. Am I right?

Normally, wchar_t is a keyword in C++ (as opposed to typedef in C).
So at first sight, I would think there should be no problem with
changing WCHAR_TYPE.  But then, I may be missing some subtile ABI point.

-- Gaby

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Ralf Baechle]

On Sun, Aug 05, 2001 at 09:48:06AM -0700, H . J . Lu wrote:

> I am working with Eric to clean up the Linux/mips configuration in
> gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They
> are the same on Linux/mips. There won't be any run-time problems. I am
> wondering if there are any compatibility problems at the compile time
> at the source and binary level. For one thing, __WCHAR_TYPE__ will be
> changed from "long int" to "int". The only thing I can think of is
> the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one
> I am working on will be the first gcc 3.x for Linux/mips. So there
> shouldn't be any problems. Am I right?

The MIPS ABI defines wchar_t to long.  So please go ahead and make the
change.

  Ralf

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Ralf Baechle <ralf@oss.sgi.com> writes:

> On Sun, Aug 05, 2001 at 09:48:06AM -0700, H . J . Lu wrote:
>
>> I am working with Eric to clean up the Linux/mips configuration in
>> gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They
>> are the same on Linux/mips. There won't be any run-time problems. I am
>> wondering if there are any compatibility problems at the compile time
>> at the source and binary level. For one thing, __WCHAR_TYPE__ will be
>> changed from "long int" to "int". The only thing I can think of is
>> the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one
>> I am working on will be the first gcc 3.x for Linux/mips. So there
>> shouldn't be any problems. Am I right?
>
> The MIPS ABI defines wchar_t to long.  So please go ahead and make the
> change.

I'm confused.  The ABI defines it to be long - and he should change it
nevertheless?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Eric Christopher]

> I am working on will be the first gcc 3.x for Linux/mips. So there
> shouldn't be any problems. Am I right?

I _think_ you are ok doing this.

I just noticed from your patch that you set the size to 32-bits.  Please
set it to BITS_PER_WORD.

-eric

-- 
Look out behind you!

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Eric Christopher]

> > The MIPS ABI defines wchar_t to long.  So please go ahead and make the
> > change.
> 
> I'm confused.  The ABI defines it to be long - and he should change it
> nevertheless?
> 

Also depends on which MIPS ABI :)  I think it is ok to change though.


-- 
Look out behind you!

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Thiemo Seufer]

Eric Christopher wrote:
> 
> > I am working on will be the first gcc 3.x for Linux/mips. So there
> > shouldn't be any problems. Am I right?
> 
> I _think_ you are ok doing this.
> 
> I just noticed from your patch that you set the size to 32-bits.  Please
> set it to BITS_PER_WORD.

I don't know if this is an good idea. BITS_PER_WORD is 64bit for mips64,
this might be wrong for wchar_t. At least the code for irix6 defines
WCHAR_TYPE_SIZE == 32.


Thiemo

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Eric Christopher]

> I don't know if this is an good idea. BITS_PER_WORD is 64bit for mips64,
> this might be wrong for wchar_t. At least the code for irix6 defines
> WCHAR_TYPE_SIZE == 32.
> 

Hrm.  You might be right.  I was thinking that would be correct though.
AFAICT from reading the c++ standard, it doesn't care about the size of
wchar_t as long as it is large enough to hold the values from the
supported locales.

Perhaps some c++ expert could help with this a bit?  Benjamin is there a
problem if wchar_t becomes 64-bits?

-eric

-- 
Look out behind you!

Re: Changing WCHAR_TYPE from "long int" to "int"?

[H . J . Lu]

On Mon, Aug 06, 2001 at 03:12:56PM +0100, Eric Christopher wrote:
> 
> > I am working on will be the first gcc 3.x for Linux/mips. So there
> > shouldn't be any problems. Am I right?
> 
> I _think_ you are ok doing this.
> 
> I just noticed from your patch that you set the size to 32-bits.  Please
> set it to BITS_PER_WORD.
> 

BITS_PER_WORD is not right. That is what prompted me to make the
change.  There are a few things about the MIPS ABI:

1. We do follow the ABI part.
2. We care much less about the API part. That is in the section 6 where
wchar_t is defined.
3. On mips, sizeof (int) == sizeof (long int).

But BITS_PER_WORD can be 32 or 64, depending on TARGET_LONG64. As for
WCHAR_TYPE, it should be `int' regardless of TARGET_LONG64. For most of
the 64bit Linux targets, sizeof (int) should be 32bit. That means
WCHAR_TYPE_SIZE should be 32 for mips.


H.J.

Re: Changing WCHAR_TYPE from "long int" to "int"?

[H . J . Lu]

On Mon, Aug 06, 2001 at 03:41:28PM +0100, Eric Christopher wrote:
> 
> > I don't know if this is an good idea. BITS_PER_WORD is 64bit for mips64,
> > this might be wrong for wchar_t. At least the code for irix6 defines
> > WCHAR_TYPE_SIZE == 32.
> > 
> 
> Hrm.  You might be right.  I was thinking that would be correct though.
> AFAICT from reading the c++ standard, it doesn't care about the size of
> wchar_t as long as it is large enough to hold the values from the
> supported locales.
> 
> Perhaps some c++ expert could help with this a bit?  Benjamin is there a
> problem if wchar_t becomes 64-bits?

Yes. Gcc won't even compile since cpp uses MAX_WCHAR_TYPE_SIZE, which
is defined as WCHAR_TYPE_SIZE and has be to a constant. But mips'
BITS_PER_WORD is not avaiable for cpp. Besides, we use 32bit wchar_t
on most of the 64bit Linux targets. Why do we want to use 64 for
mips64? Check out WCHAR_TYPE_SIZE on ia64 and alpha, which are all
64bit Linux targets.


H.J.

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Eric Christopher]

> Yes. Gcc won't even compile since cpp uses MAX_WCHAR_TYPE_SIZE, which
> is defined as WCHAR_TYPE_SIZE and has be to a constant. But mips'
> BITS_PER_WORD is not avaiable for cpp. Besides, we use 32bit wchar_t
> on most of the 64bit Linux targets. Why do we want to use 64 for
> mips64? Check out WCHAR_TYPE_SIZE on ia64 and alpha, which are all
> 64bit Linux targets.
> 

Right.  alpha doesn't define WCHAR_TYPE_SIZE, ia64 seems to do what you
want...

-eric


-- 
Look out behind you!

Re: Changing WCHAR_TYPE from "long int" to "int"?

[H . J . Lu]

On Mon, Aug 06, 2001 at 04:33:54PM +0100, Eric Christopher wrote:
> 
> > Yes. Gcc won't even compile since cpp uses MAX_WCHAR_TYPE_SIZE, which
> > is defined as WCHAR_TYPE_SIZE and has be to a constant. But mips'
> > BITS_PER_WORD is not avaiable for cpp. Besides, we use 32bit wchar_t
> > on most of the 64bit Linux targets. Why do we want to use 64 for
> > mips64? Check out WCHAR_TYPE_SIZE on ia64 and alpha, which are all
> > 64bit Linux targets.
> > 
> 
> Right.  alpha doesn't define WCHAR_TYPE_SIZE, ia64 seems to do what you
> want...

alpha does:

# grep WCHAR_TYPE defaults.h config/alpha/linux.h
defaults.h:#ifndef WCHAR_TYPE_SIZE
defaults.h:#define WCHAR_TYPE_SIZE INT_TYPE_SIZE
config/alpha/linux.h:#undef WCHAR_TYPE
config/alpha/linux.h:#define WCHAR_TYPE "int"
# grep INT_TYPE_SIZE config/alpha/*.h
config/alpha/alpha.h:#define INT_TYPE_SIZE 32

So WCHAR_TYPE_SIZE is 32 for Linux/alpha.


H.J.

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Ralf Baechle]

On Mon, Aug 06, 2001 at 12:10:59PM +0200, Andreas Jaeger wrote:

> >> I am working with Eric to clean up the Linux/mips configuration in
> >> gcc 3.x. I'd like to change WCHAR_TYPE from "long int" to "int". They
> >> are the same on Linux/mips. There won't be any run-time problems. I am
> >> wondering if there are any compatibility problems at the compile time
> >> at the source and binary level. For one thing, __WCHAR_TYPE__ will be
> >> changed from "long int" to "int". The only thing I can think of is
> >> the C++ libraries. But gcc 3.x doesn't work on Linux/mips. The one
> >> I am working on will be the first gcc 3.x for Linux/mips. So there
> >> shouldn't be any problems. Am I right?
> >
> > The MIPS ABI defines wchar_t to long.  So please go ahead and make the
> > change.
> 
> I'm confused.  The ABI defines it to be long - and he should change it
> nevertheless?

It's defined as a "long", not "long int" so we're obviously off by a tiny
bit.

H.J. - why did you want to change this type anyway?  "long int" and "int"
both have the same size and signedness so there isn't any incompatibility
anyway?

  Ralf

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Eric Christopher]

> 
> alpha does:
> 
> # grep WCHAR_TYPE defaults.h config/alpha/linux.h
> defaults.h:#ifndef WCHAR_TYPE_SIZE
> defaults.h:#define WCHAR_TYPE_SIZE INT_TYPE_SIZE
> config/alpha/linux.h:#undef WCHAR_TYPE
> config/alpha/linux.h:#define WCHAR_TYPE "int"
> # grep INT_TYPE_SIZE config/alpha/*.h
> config/alpha/alpha.h:#define INT_TYPE_SIZE 32
> 
> So WCHAR_TYPE_SIZE is 32 for Linux/alpha.
> 

Ah ha.  I'd not looked into defaults.h. Ok.  Nevermind then.

-eric


-- 
Look out behind you!

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Ralf Baechle]

On Mon, Aug 06, 2001 at 03:27:49PM +0100, Eric Christopher wrote:

> > > The MIPS ABI defines wchar_t to long.  So please go ahead and make the
> > > change.
> > 
> > I'm confused.  The ABI defines it to be long - and he should change it
> > nevertheless?
> > 
> 
> Also depends on which MIPS ABI :)  I think it is ok to change though.

MIPS psABI 3.0.

  Ralf

Re: Changing WCHAR_TYPE from "long int" to "int"?

[H . J . Lu]

On Mon, Aug 06, 2001 at 06:20:50PM +0200, Ralf Baechle wrote:
> 
> H.J. - why did you want to change this type anyway?  "long int" and "int"
> both have the same size and signedness so there isn't any incompatibility
> anyway?
> 

All Linux targets should use a 32bit type, `int', for wchar_t. `long'
is 64bit for mips64.

Like I said, we don't use the mips API, only the ABI.


H.J.

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Gabriel Dos_Reis]

| > I'm confused.  The ABI defines it to be long - and he should change it
| > nevertheless?
| 
| It's defined as a "long", not "long int" so we're obviously off by a tiny
| bit.

As far as far C++ is concerned, there is no pedantic difference
between "long" and "long int" and "signed long int".

-- Gaby

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Ralf Baechle]

On Mon, Aug 06, 2001 at 07:04:36PM +0200, Gabriel Dos_Reis wrote:

> | > I'm confused.  The ABI defines it to be long - and he should change it
> | > nevertheless?
> | 
> | It's defined as a "long", not "long int" so we're obviously off by a tiny
> | bit.
> 
> As far as far C++ is concerned, there is no pedantic difference
> between "long" and "long int" and "signed long int".

Guess why I said a tiny bit :-)

  Ralf

Re: Changing WCHAR_TYPE from "long int" to "int"?

[Ralf Baechle]

On Mon, Aug 06, 2001 at 03:41:28PM +0100, Eric Christopher wrote:

> Hrm.  You might be right.  I was thinking that would be correct though.
> AFAICT from reading the c++ standard, it doesn't care about the size of
> wchar_t as long as it is large enough to hold the values from the
> supported locales.
> 
> Perhaps some c++ expert could help with this a bit?  Benjamin is there a
> problem if wchar_t becomes 64-bits?

On 64-bit MIPS ABI compliant machines I see wchar_t defined to __int32_t
which again is int.

  Ralf

cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

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

cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

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

Re: cross-mipsel-linux-ld --prefix library path

[Geert Uytterhoeven]

On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:
> 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

That's normal, I have

| tux$ ls -li /usr/local/bin/*ld /usr/local/*/bin/ld
|   62976 -rwxr-xr-x    2 root     staff      946678 Jun 11 15:47 /usr/local/bin/m68k-amigaos-ld*
|   63675 -rwxr-xr-x    2 root     staff     1356730 Mar 12 11:17 /usr/local/bin/m68k-linux-ld*
|   63660 -rwxr-xr-x    2 root     staff     1545874 Mar 12 11:16 /usr/local/bin/powerpc-linux-ld*
|   62976 -rwxr-xr-x    2 root     staff      946678 Jun 11 15:47 /usr/local/m68k-amigaos/bin/ld*
|   63675 -rwxr-xr-x    2 root     staff     1356730 Mar 12 11:17 /usr/local/m68k-linux/bin/ld*
|   63660 -rwxr-xr-x    2 root     staff     1545874 Mar 12 11:16 /usr/local/powerpc-linux/bin/ld*
| tux$ 

The `duplicates' are just hard links (compare the inode numbers), so they don't waste real space (except for the directory entries :-).

BTW, I used --prefix=/usr/local.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

MIPS ABI (was: Changing WCHAR_TYPE from "long int" to "int"?)

[Paul Kasper]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Ralf Baechle wrote:
> 
> On Mon, Aug 06, 2001 at 03:27:49PM +0100, Eric Christopher wrote:
> 
> > > > The MIPS ABI defines wchar_t to long.  So please go ahead and make the
> > > > change.
> > >
> > > I'm confused.  The ABI defines it to be long - and he should change it
> > > nevertheless?
> > >
> >
> > Also depends on which MIPS ABI :)  I think it is ok to change though.
> 
> MIPS psABI 3.0.
> 
>   Ralf

Where can I find the MIPS ABI?

--
Paul K.
-- 
 /"\ . . . . . . . . . . . . . . . /"\
 \ /   ASCII Ribbon Campaign       \ /     Paul R. Kasper
  X    - NO HTML/RTF in e-mail      X      Patton Electronics Co.
 / \   - NO MSWord docs in e-mail  / \     301-975-1000 x173

[-- Attachment #2: Card for Paul Kasper --]
[-- Type: text/x-vcard, Size: 311 bytes --]

begin:vcard 
n:Kasper;Paul
tel;fax:301-869-9293
tel;work:301-975-1000 x173
x-mozilla-html:FALSE
url:www.patton.com
org:Patton Electronics Co.;Central Office Products
adr:;;7622 Rickenbacker Drive;Gaithersburg;MD;20879;USA
version:2.1
email;internet:paul@patton.com
x-mozilla-cpt:;10912
fn:Paul Kasper
end:vcard

Re: MIPS ABI (was: Changing WCHAR_TYPE from "long int" to "int"?)

[Ralf Baechle]

On Tue, Aug 07, 2001 at 07:52:22AM -0400, Paul Kasper wrote:

> Where can I find the MIPS ABI?

www.eagercon.com is one of the places where it's online.

  Ralf

Re: cross-mipsel-linux-ld --prefix library path

[Maciej W. Rozycki]

On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:

> 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.

 You don't need to specify "--prefix=/usr/mipsel-linux" for building
cross-binutils.  The scripts will add the target alias automatically for
files that need it -- if you look at the scripts,
"${prefix}/${target_alias}" is the so called "tooldir". 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

Cool.  So, what is the purpose of having both $prefix/bin/mipsel-linux-ld
and $prefix/mipsel-linux/bin/ld?

Also, why is glibc installing libraries into $prefix/lib when
mipsel-linux-ld is looking in $prefix/mipsel-linux/lib?

Regards,
Brad

----- Original Message -----
From: "Geert Uytterhoeven" <Geert.Uytterhoeven@sonycom.com>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 3:40 AM
Subject: Re: cross-mipsel-linux-ld --prefix library path


> On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:
> > 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
>
> That's normal, I have
>
> | tux$ ls -li /usr/local/bin/*ld /usr/local/*/bin/ld
> |   62976 -rwxr-xr-x    2 root     staff      946678 Jun 11 15:47
/usr/local/bin/m68k-amigaos-ld*
> |   63675 -rwxr-xr-x    2 root     staff     1356730 Mar 12 11:17
/usr/local/bin/m68k-linux-ld*
> |   63660 -rwxr-xr-x    2 root     staff     1545874 Mar 12 11:16
/usr/local/bin/powerpc-linux-ld*
> |   62976 -rwxr-xr-x    2 root     staff      946678 Jun 11 15:47
/usr/local/m68k-amigaos/bin/ld*
> |   63675 -rwxr-xr-x    2 root     staff     1356730 Mar 12 11:17
/usr/local/m68k-linux/bin/ld*
> |   63660 -rwxr-xr-x    2 root     staff     1545874 Mar 12 11:16
/usr/local/powerpc-linux/bin/ld*
> | tux$
>
> The `duplicates' are just hard links (compare the inode numbers), so they
don't waste real space (except for the directory entries :-).
>
> BTW, I used --prefix=/usr/local.
>
> Gr{oetje,eeting}s,
>
> Geert

Re: cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

Cool.  So, what is the purpose of having both $prefix/bin/mipsel-linux-ld
and $prefix/mipsel-linux/bin/ld?

Also, why is glibc installing libraries into $prefix/lib when
mipsel-linux-ld is looking in $prefix/mipsel-linux/lib?

Regards,
Brad

----- Original Message -----
From: "Geert Uytterhoeven" <Geert.Uytterhoeven@sonycom.com>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 3:40 AM
Subject: Re: cross-mipsel-linux-ld --prefix library path


> On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:
> > 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
>
> That's normal, I have
>
> | tux$ ls -li /usr/local/bin/*ld /usr/local/*/bin/ld
> |   62976 -rwxr-xr-x    2 root     staff      946678 Jun 11 15:47
/usr/local/bin/m68k-amigaos-ld*
> |   63675 -rwxr-xr-x    2 root     staff     1356730 Mar 12 11:17
/usr/local/bin/m68k-linux-ld*
> |   63660 -rwxr-xr-x    2 root     staff     1545874 Mar 12 11:16
/usr/local/bin/powerpc-linux-ld*
> |   62976 -rwxr-xr-x    2 root     staff      946678 Jun 11 15:47
/usr/local/m68k-amigaos/bin/ld*
> |   63675 -rwxr-xr-x    2 root     staff     1356730 Mar 12 11:17
/usr/local/m68k-linux/bin/ld*
> |   63660 -rwxr-xr-x    2 root     staff     1545874 Mar 12 11:16
/usr/local/powerpc-linux/bin/ld*
> | tux$
>
> The `duplicates' are just hard links (compare the inode numbers), so they
don't waste real space (except for the directory entries :-).
>
> BTW, I used --prefix=/usr/local.
>
> Gr{oetje,eeting}s,
>
> Geert

Re: cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

----- Original Message -----
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 10:10 AM
Subject: Re: cross-mipsel-linux-ld --prefix library path


>  You don't need to specify "--prefix=/usr/mipsel-linux" for building
> cross-binutils.  The scripts will add the target alias automatically for
> files that need it -- if you look at the scripts,
> "${prefix}/${target_alias}" is the so called "tooldir".

Oh...  The mysteries of cross-toolchain building.  Thanks.

So if I leave out --prefix alogether, will "make install" overwrite any x86
stuff, like that libbfd.la file I mentioned?

Regards,
Brad

Re: cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

----- Original Message -----
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 10:10 AM
Subject: Re: cross-mipsel-linux-ld --prefix library path


>  You don't need to specify "--prefix=/usr/mipsel-linux" for building
> cross-binutils.  The scripts will add the target alias automatically for
> files that need it -- if you look at the scripts,
> "${prefix}/${target_alias}" is the so called "tooldir".

Oh...  The mysteries of cross-toolchain building.  Thanks.

So if I leave out --prefix alogether, will "make install" overwrite any x86
stuff, like that libbfd.la file I mentioned?

Regards,
Brad

Re: cross-mipsel-linux-ld --prefix library path

[Maciej W. Rozycki]

On Tue, 7 Aug 2001, Bradley D. LaRonde wrote:

> So if I leave out --prefix alogether, will "make install" overwrite any x86
> stuff, like that libbfd.la file I mentioned?

 Well, libbfd and libopcodes do conflict indeed.  In theory they can
support multiple targets at once, but I'm unsure if that's stable enough. 
I use "--enable-shared --disable-static
--libdir='${exec_prefix}'/mipsel-linux/i386-linux/lib" in the configure's
command line for i386-linux-hosted cross-binutils.  As a result the
libraries get installed out of the way but they are still used by
cross-binutils thanks to the RPATH tag being set appropriately in ELF
headers by libtool. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: cross-mipsel-linux-ld --prefix library path

[Steve Langasek]

On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:

> 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

The places you /want/ these to show up are /usr/mipsel-linux/bin/ld and
/usr/bin/mipsel-linux-ld.  The reason for having two copies is that when
you're calling these tools directly (or from a make script), you want them to
be in your path, so you want them to have a unique name
(/usr/bin/mipsel-linux-ld); but internally, I believe the tools prefer /not/
to have to mess with the name mangling used there, so instead they look for a
tool with the normal name (ld) in an architecture-specific directory
(/usr/mipsel-linux/bin).

Steve Langasek
postmodern programmer

Re: cross-mipsel-linux-ld --prefix library path

[Steve Langasek]

On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:

> 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

The places you /want/ these to show up are /usr/mipsel-linux/bin/ld and
/usr/bin/mipsel-linux-ld.  The reason for having two copies is that when
you're calling these tools directly (or from a make script), you want them to
be in your path, so you want them to have a unique name
(/usr/bin/mipsel-linux-ld); but internally, I believe the tools prefer /not/
to have to mess with the name mangling used there, so instead they look for a
tool with the normal name (ld) in an architecture-specific directory
(/usr/mipsel-linux/bin).

Steve Langasek
postmodern programmer

Re: cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

OK, so say I leave off --prefix entirely, and the binutils get installed in
/usr/bin and /usr/mipsel-linux/bin.  Now, I suppose that mipsel-linux-ld
will look for libs in /usr/mipsel-linux/lib, which is cool.  But, how to I
convince the cross-built glibc that's where his libraries belong?
 Just --prefix=/usr/mipsel-linux to glibc's configure?

Regards,
Brad

----- Original Message -----
From: "Steve Langasek" <vorlon@netexpress.net>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 10:42 AM
Subject: Re: cross-mipsel-linux-ld --prefix library path


> On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:
>
> > 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
>
> The places you /want/ these to show up are /usr/mipsel-linux/bin/ld and
> /usr/bin/mipsel-linux-ld.  The reason for having two copies is that when
> you're calling these tools directly (or from a make script), you want them
to
> be in your path, so you want them to have a unique name
> (/usr/bin/mipsel-linux-ld); but internally, I believe the tools prefer
/not/
> to have to mess with the name mangling used there, so instead they look
for a
> tool with the normal name (ld) in an architecture-specific directory
> (/usr/mipsel-linux/bin).
>
> Steve Langasek
> postmodern programmer
>
>

Re: cross-mipsel-linux-ld --prefix library path

[Bradley D. LaRonde]

OK, so say I leave off --prefix entirely, and the binutils get installed in
/usr/bin and /usr/mipsel-linux/bin.  Now, I suppose that mipsel-linux-ld
will look for libs in /usr/mipsel-linux/lib, which is cool.  But, how to I
convince the cross-built glibc that's where his libraries belong?
 Just --prefix=/usr/mipsel-linux to glibc's configure?

Regards,
Brad

----- Original Message -----
From: "Steve Langasek" <vorlon@netexpress.net>
To: "Bradley D. LaRonde" <brad@ltc.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 07, 2001 10:42 AM
Subject: Re: cross-mipsel-linux-ld --prefix library path


> On Mon, 6 Aug 2001, Bradley D. LaRonde wrote:
>
> > 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
>
> The places you /want/ these to show up are /usr/mipsel-linux/bin/ld and
> /usr/bin/mipsel-linux-ld.  The reason for having two copies is that when
> you're calling these tools directly (or from a make script), you want them
to
> be in your path, so you want them to have a unique name
> (/usr/bin/mipsel-linux-ld); but internally, I believe the tools prefer
/not/
> to have to mess with the name mangling used there, so instead they look
for a
> tool with the normal name (ld) in an architecture-specific directory
> (/usr/mipsel-linux/bin).
>
> Steve Langasek
> postmodern programmer
>
>

Re: MIPS ABI (was: Changing WCHAR_TYPE from "long int" to "int"?)

[H . J . Lu]

On Tue, Aug 07, 2001 at 07:52:22AM -0400, Paul Kasper wrote:
> > 
> > MIPS psABI 3.0.
> > 
> >   Ralf
> 
> Where can I find the MIPS ABI?
> 

ftp://oss.sgi.com/pub/linux/mips/doc/ABI/


H.J.

Re: cross-mipsel-linux-ld --prefix library path

[Steve Langasek]

On Tue, 7 Aug 2001, Bradley D. LaRonde wrote:

> OK, so say I leave off --prefix entirely, and the binutils get installed in
> /usr/bin and /usr/mipsel-linux/bin.  Now, I suppose that mipsel-linux-ld
> will look for libs in /usr/mipsel-linux/lib, which is cool.  But, how to I
> convince the cross-built glibc that's where his libraries belong?
>  Just --prefix=/usr/mipsel-linux to glibc's configure?

That should be enough to force glibc to use /usr/mipsel-linux, but I don't
think it's correct to use that as a /configure/ option.  Effectively,
libraries used for cross-building should be identical to the native libraries
in every way[1], only installed in a different place on the system.  You would
never /run/ glibc-based applications against /usr/mipsel-linux on a native
system.

On Debian, I find that dpkg-cross is a very useful utility.  You can pass it
the filename of a package from another architecture, as well as the
architecture it belongs to, and it will reconstruct an Architecture: all
package that places the libraries under /usr/<arch>-linux.  This seems a bit
easier than trying to worry about install directories for glibc at compile
time.

HTH,
Steve Langasek
postmodern programmer

[1] ok, with the exception of /usr/lib/libc.so, which is not a library at all,
    but rather a GNU linker script.  dpkg-cross also takes care of rewriting
    this script, which I found rather impressive the first time I saw it
    happen.

Re: cross-mipsel-linux-ld --prefix library path

[Steve Langasek]

On Tue, 7 Aug 2001, Bradley D. LaRonde wrote:

> OK, so say I leave off --prefix entirely, and the binutils get installed in
> /usr/bin and /usr/mipsel-linux/bin.  Now, I suppose that mipsel-linux-ld
> will look for libs in /usr/mipsel-linux/lib, which is cool.  But, how to I
> convince the cross-built glibc that's where his libraries belong?
>  Just --prefix=/usr/mipsel-linux to glibc's configure?

That should be enough to force glibc to use /usr/mipsel-linux, but I don't
think it's correct to use that as a /configure/ option.  Effectively,
libraries used for cross-building should be identical to the native libraries
in every way[1], only installed in a different place on the system.  You would
never /run/ glibc-based applications against /usr/mipsel-linux on a native
system.

On Debian, I find that dpkg-cross is a very useful utility.  You can pass it
the filename of a package from another architecture, as well as the
architecture it belongs to, and it will reconstruct an Architecture: all
package that places the libraries under /usr/<arch>-linux.  This seems a bit
easier than trying to worry about install directories for glibc at compile
time.

HTH,
Steve Langasek
postmodern programmer

[1] ok, with the exception of /usr/lib/libc.so, which is not a library at all,
    but rather a GNU linker script.  dpkg-cross also takes care of rewriting
    this script, which I found rather impressive the first time I saw it
    happen.