Subject: Re: Error report for ELF

From: Vincent PENNE <[email-masked]>
Date: Wed, 01 Jul 1998 19:28:53 +0200

I wonder,
is it the right place where to speak about ELF ? Are there anybody out
there trying also to build these ELF tools ? Does anybody except Philip
Blundell has succeeded in builing them on his RiscPC computer ?

 Vincent.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Matthew Wilcox <[email-masked]>
Date: Wed, 1 Jul 1998 18:51:35 +0100 (BST)

Vincent PENNE
> Blundell has succeeded in builing them on his RiscPC computer ?

Phil Norman and myself have also been trying them - did you miss our post?
I've been busy of late, but I should be back into it next week.

-- 
Set Alias$Case Set Alias$[ |||| |MSet Alias$Otherwise Set Alias$[ \ Matthew
"" |MSet Alias$When If %0=%%0 Then Set Alias$[ "" ||MIf %0=%%0    \ Wilcox
Then Set Alias$Otherwise Set Alias$[ |||||||||||||||| ||MIf       \
%0=%%0 Then Set Alias$When Set Alias$[ ||||||||||||||||
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 19:06:36 +0100

>is it the right place where to speak about ELF ?

I think there is a specific list, but this one will probably do as well.

>Blundell has succeeded in builing them on his RiscPC computer ?

I must admit I haven't even tried a native build yet.  I believe the Corel 
guys do things that way, though.

p.

---

From: Pat Beirne <[email-masked]>
Date: Wed, 01 Jul 1998 13:56:57 -0400

> guys do things that way, though.

Yes, we do. Our version of the source tree will be posted through
our NetWinder CVS system. You can register with netwinder.org
to get an account.

Pat
CCC

---

From: Stefan Voss <[email-masked]>
Date: Thu, 02 Jul 1998 09:20:13 +0200

> Blundell has succeeded in builing them on his RiscPC computer ?

Well, I'm trying to build ELF. I've now successfully build the ELF
binutils but have a problem when building the ELF gcc.

cccp and cc1 build ok but once cc1 is build it seems to be used for 
further compilation steps. I get "unresolved symbols" messages for symbols
that start with "__". These are ELF symbols, aren't they? a.out object
files usually have only one "_", right?

BTW, I think this is the right place to speak about ELF. We're starting to
move from a.out to ELF so we're likely to see platform specific problems
for which this mailing list is the right place.

Of course, if we come across an ELF specific (platform independent)
problem it should be discussed (also) elsewhere.

>  Vincent.

Regards,
   Stefan

-- 
Stefan Voss
([email-masked])

---

From: Philip Blundell <[email-masked]>
Date: Thu, 02 Jul 1998 09:40:07 +0100

>files usually have only one "_", right?

No; ELF symbols have _no_ leading underscore.  The `__' symbols are probably 
functions in libgcc.  If you post the actual messages I might be able to guess 
what's wrong.

p.

---

From: "Scott Bambrough" <[email-masked]>
Date: Thu, 02 Jul 1998 09:04:32 -0400

Philip Blundell wrote:
> I must admit I haven't even tried a native build yet.  I believe the > Corel guys do things that way, though.
> 
Thats correct.  We currently build GCC, binutils, glibc and gdb
natively.  We also build most of the programs on the NetWinder natively
using ELF and the tools Phil provides.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Stefan Hanske <[email-masked]>
Date: Thu, 2 Jul 1998 15:43:17 +0200 (METDST)

> Blundell has succeeded in builing them on his RiscPC computer ?

I'm currently trying, I had some problems to figure out where to link the
kernel includes for compiling glibc. It's compiling now at home while I'm
sitting here in the computer cabinet of the university reading my 60 new
mails, so I just don't know weather it works or not.

I tried binutils-2.9.1.0.6, gcc-2.8.1 (worked fine for now, as cross
compiler) and glibc-2.0.94 with the patches mentioned earlier in this
list.

If gcc get's through, I will try to build a native elf-gcc to see if libc
works.

----------------------------------------------------------
|mailto: Stefan Hanske ([email-masked] |
|WWW : http://www.rzuser.uni-heidelberg.de/~shanske      |
|phone: I'm not silly                                    |
|--------------------------------------------------------|
| And don't forget to remember what you remembered not   |
| to forget to remember...				 |
----------------------------------------------------------

---

From: Stefan Voss <[email-masked]>
Date: Thu, 09 Jul 1998 18:17:53 +0200

In message <[email-masked]>

> functions in libgcc.  If you post the actual messages I might be able to guess 

Then I probably did something wrong. I'm going to start (almost) from
scratch.

Here's a more detailed description of errors I came across when
compiling gcc 2.8.1 for ELF. Previous steps like compiling gcc and
binutils for a.out and compiling binutils for ELF were ok.
Configure was run as follows:

# ./configure  --target=arm-unknown-linuxelf --host=arm-unknown-linuxaout --prefix=/usr/local

So the system should produce ELF but run on an a.out machine.

[voss@yoda gcc-2.8.1]$ make LANGUAGES=c
...
rm -f tmplibgcc1.a libgcc1.S
cp ./config/arm/lib1funcs.asm libgcc1.S
for name in _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx; \
do \
  echo ${name}; \
  ./xgcc -B./ -O2 -fomit-frame-pointer  -DCROSS_COMPILE -DIN_GCC    -g
-I./include  -g0 -I. -I. -I./config -c -DL${name} libgcc1.S; \ 
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  mv libgcc1.o ${name}.o; \
  /usr/local/arm-unknown-linuxelf/bin/ar rc tmplibgcc1.a ${name}.o; \
  rm -f ${name}.o; \
done
_udivsi3
_divsi3
_umodsi3
_modsi3
_dvmd_lnx
libgcc1.S:430: asm/unistd.h: No such file or directory

Hmm, asm/unistd.h cannot be found but I'm sure I have such a file

[voss@yoda include]$ ls -l /usr/include/asm/unistd.h
-rw-r--r--   1 root     root        11931 Jun 20 13:49 /usr/include/asm/unistd.h

Let's see what directories unistd.h is looked for:

[voss@yoda gcc-2.8.1]$ ./xgcc -v  -B./ -O2 -fomit-frame-pointer 
-DCROSS_COMPILE -DIN_GCC    -g -I./include  -g0 -I. -I. -I./config -c
-DL_dvmd_lnx libgcc1.S  
Reading specs from ./specs
gcc version 2.8.1
 ./cpp -lang-asm -v -I./include -I. -I. -I./config -isystem ./include
-undef -$ -Dunix -Darm -Dlinux -D__ELF__ -D__unix__ -D__arm__ -D__linux__
-D__ELF__ -D__unix -D__arm -D__linux -Asystem(unix) -Asystem(posix)
-Acpu(arm) -Amachine(arm) -D__ASSEMBLER__ -D__CHAR_UNSIGNED__
-D__OPTIMIZE__ -g -g0 -D__ARM_ARCH_3__ -D__APCS_26__ -DCROSS_COMPILE
-DIN_GCC -DL_dvmd_lnx libgcc1.S /tmp/cca10581.s     
GNU CPP version 2.8.1 (ARM GNU/Linux with ELF)
#include "..." search starts here:
#include <...> search starts here:
 include
 .
 config
 include
End of search list.
libgcc1.S:430: asm/unistd.h: No such file or directory

So asm/unistd.h is not found because /usr/include isn't searched. 
That probably ok because we don't want to handle system includes at
this stage of the compilation. I'll just make a link so that
asm/unistd.h is found.

[voss@yoda asm]$ pwd  
/export/gcc-2.8.1/include/asm
[voss@yoda asm]$ ls -l
total 0
lrwxrwxrwx   1 voss     voss           25 Jul  9 13:16 unistd.h -> /usr/include/asm/unistd.h

[voss@yoda gcc-2.8.1]$ make LANGUAGES=c
...
gcc -v -c -DCROSS_COMPILE -DIN_GCC    -g  -DHAVE_CONFIG_H    -I. -I. -I./config ./cp/g++spec.c
Reading specs from ./specs
gcc version 2.8.1
 /usr/lib/gcc-lib/arm-unknown-linuxaout/2.8.1/cpp -lang-c -v -I. -I.
-I./config -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -Dunix -Darm -Dlinux
-D__ELF__ -D__unix__ -D__arm__ -D__linux__ -D__ELF__ -D__unix -D__arm
-D__linux -Asystem(unix) -Asystem(posix) -Acpu(arm) -Amachine(arm)
-D__CHAR_UNSIGNED__ -g -D__ARM_ARCH_3__ -D__APCS_26__ -DCROSS_COMPILE
-DIN_GCC -DHAVE_CONFIG_H ./cp/g++spec.c /tmp/cca11608.i 
GNU CPP version 2.8.1 (ARM GNU/Linux with a.out)
#include "..." search starts here:
#include <...> search starts here:
 .
 config
 /usr/local/include
 /usr/arm-unknown-linuxaout/include
 /usr/lib/gcc-lib/arm-unknown-linuxaout/2.8.1/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/arm-unknown-linuxaout/2.8.1/cc1 /tmp/cca11608.i -quiet
-dumpbase g++spec.c -g -version -o /tmp/cca11608.s 
GNU C version 2.8.1 (arm-unknown-linuxaout) compiled by GNU C version 2.8.1.
 as -o g++spec.o /tmp/cca11608.s
gcc -v -DCROSS_COMPILE -DIN_GCC    -g  -DHAVE_CONFIG_H  -o g++ g++.o g++spec.o prefix.o \
  version.o choose-temp.o pexecute.o  obstack.o ` case "gcc -v" in "cc") echo "" ;; esac `  
Reading specs from ./specs
gcc version 2.8.1
 ld -dynamic-linker /lib/elf/ld-linux.so.2 -o g++ crt1.o crti.o
./crtbegin.o -L/usr/local/qt/lib -L.
-L/usr/lib/gcc-lib/arm-unknown-linuxaout/2.8.1
-L/usr/arm-unknown-linuxaout/lib g++.o g++spec.o prefix.o version.o
choose-temp.o pexecute.o obstack.o -lgcc -lc -lgcc ./crtend.o crtn.o  
ld: cannot open crt1.o: No such file or directory
make: *** [g++] Error 1

Why is g++ built now? I thought I only told make to build the C
compiler, not the C++ compiler. And why does ld try to produce an ELF
binary? Should that be still an a.out binary?

Maybe I have progressed too far. Isn't xgcc the result I wanted? A
C compiler running as a.out producing ELF.

Regards,
   Stefan

-- 
Stefan Voss
([email-masked])

---

From: Philip Blundell <[email-masked]>
Date: Thu, 09 Jul 1998 18:43:48 +0100

>So asm/unistd.h is not found because /usr/include isn't searched. 

That's because you told GCC to build as a cross-compiler.  You need to symlink 
/usr/include/asm into /usr/arm-linux/include/asm.

(Incidentally, you should really use `arm-linux' rather than `arm-linuxelf' as 
the machine name; the latter will probably stop working fairly soon.)

>compiler, not the C++ compiler.

I think that's a problem with the gcc makefile.  If you edit it and remove cp 
from the LANGUAGES definition you should get the result you want.

>And why does ld try to produce an ELF
>binary?

It seems to be picking up the new specs file too early.  I think this can 
happen if you have some path variable set wrong in your environment.  Check 
that things like PATH and LD_LIBRARY_PATH don't contain `.' or an empty 
component.

>C compiler running as a.out producing ELF.

Actually, yes it is.  If xgcc, cpp and libgcc.a have all been built then you 
have probably succeeded but you'll need to install them by hand if the build 
won't run to completion.

p.

---

From: Paul Koning <[email-masked]>
Date: Thu, 9 Jul 1998 15:57:35 -0400

>>>>> "Philip" == Philip Blundell <[email-masked]> writes:

 >> compiler, not the C++ compiler.

 Philip> I think that's a problem with the gcc makefile.  If you edit
 Philip> it and remove cp from the LANGUAGES definition you should get
 Philip> the result you want.

Easier is simply to say LANGUAGES=c on the make command.

Incidentally, if you do that, be sure to use that same LANGUAGES
option on the make install, otherwise it will at that time try to
build the rest.  Ugh.

	paul

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 9 Jul 1998 19:34:35 +0100 (BST)

> Then I probably did something wrong. I'm going to start (almost) from

Please continue this discussion on the [email-masked] mailing list
rather than the ARM Linux mailing list.  See my web page for the subscription
instructions.  Thanks.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Thu, 09 Jul 1998 22:03:28 +0100

>Easier is simply to say LANGUAGES=c on the make command.

That's the point.  Under some circumstances that doesn't work and you still 
end up with everything getting built.

p.

---

From: Stefan Voss <[email-masked]>
Date: Sat, 11 Jul 1998 10:49:44 +0200

In message <[email-masked]>,
     Philip Blundell wrote:

> [...]

OK, that did the trick. Thanks!

> that things like PATH and LD_LIBRARY_PATH don't contain `.' or an empty 

Good guess again. I had LIBRARY_PATH and LD_LIBRARY_PATH ending with a
colon so that the current working directory was searched for libs. Now the
compilation ends sucessfully. 

As requested by Russell I'm going to direct further ELF questions/problems
to the elf-arm mailing list.

Regards,
   Stefan

-- 
Stefan Voss
([email-masked])