RE: Crosstool chain on MinGW

["Manoj Verma, Noida" <manojv at noida dot hcltech dot com>]

Hi Kai,
I really appreciate the guidance/feebacks given by you.

I have finally successfully build the 'arm-linux' tool chain over MinGW.
I am using GCC-3.2.2.

I am using Glibc-2.2.3. The executable 'tst_arm-linux-gx' given by you
doesn't work on my target probably becuase my Glibc is older than what you
have used to build this executable.

I have still some concerns about the tool chain:
1) $arm-linux-gcc test.c -o myout
   $arm-linux-readelf -l myout

It says...
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00008034 0x00008034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0000f4 0x000080f4 0x000080f4 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x00008000 0x00008000 0x004ec 0x004ec R E 0x8000
  LOAD           0x0004ec 0x000104ec 0x000104ec 0x00110 0x0012c RW  0x8000
 
BUT WHEN I DO
   
   $arm-linux-gcc -c test.c 
   $arm-linux-ld test.o -o muout <crt*.o>
   $arm-linux-readelf -l myout

It says...
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00008034 0x00008034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0000f4 0x000080f4 0x000080f4 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /usr/lib/ld.so.1]
  LOAD           0x000000 0x00008000 0x00008000 0x004ec 0x004ec R E 0x8000
  LOAD           0x0004ec 0x000104ec 0x000104ec 0x00110 0x0012c RW  0x8000

WHY THERE IS THIS DIFFERENCE OF       [Requesting program interpreter:
xxxxxxx]

My Specs reads like:
%{h*} %{version:-v}    %{b} %{Wl,*:%*}    %{static:-Bstatic}
%{shared:-shared}    %{symbolic:-Bsymbolic}    %{rdynamic:-export-dynamic}
%{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}    -X
%{mbig-endian:-EB} -m armelf_linux -p


Regards,
Manoj


> -----Original Message-----
> From: Kai Ruottu [mailto:kai_ruottu@mbnet.fi]
> Sent: Tuesday, November 18, 2003 7:41 PM
> To: Manoj Verma, Noida
> Subject: RE: Crosstool chain on MinGW
> 
> 
> "Manoj Verma, Noida" <manojv@noida.hcltech.com> wrote:
> 
> > By making the entry of ld-linux.so.2 in 'libc.so' script as,
> >      GROUP ( libc.so.6 ld-linux.so.2 libc_nonshared.a )
> > 
> > The linking errors are gone.
> > 
> > But, when I try to execute the generated image on the 
> target it says:
> > bash: ./myExe no such file and directory.
> > 
> > On doing "readelf" over this image it reveals the following 
> statement in the
> > "Program header" section:
> > "[Requesting program interpreter: /usr/lib/ld.so.1]"
> > 
> > On my target board there is no such file in the required path.
> > So I copied the ld-2.2.3.so to  /usr/lib/directory and 
> created ld.so.1 as a
> > softlink to the ld-2.2.3.so.
> 
>  The 'ld.so.1' and 'ld-linux.so.2' are two names for just the same
> thing. Earlier it could have been named as 'ld.so.1', this is the SVR4
> name for it, but most Linuces should now use the 'ld-linux.so.2', also
> the ARM-one.  Some like PPC, MIPS,... still use the SVR4 name for
> some peculiar reason, or their developers don't yet think that they 
> should be afraid of SCO/Caldera accusing them for direct copying...
> 
>  BTW, the 'http://www.caldera.com/developers/devspecs' has
> those SVR4 ABI docs for generic SVR4 and the i386 plus MIPS
> Supplements in PDF format...
> 
>  A 'readelf -l' from an executable produced by my 'arm-linux-gnu'
> target toolchain gives:
> 
> Elf file type is EXEC (Executable file)
> Entry point 0x200058c
> There are 6 program headers, starting at offset 52
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg 
> Align
>   PHDR           0x000034 0x02000034 0x02000034 0x000c0 
> 0x000c0 R E 0x4
>   INTERP         0x0000f4 0x020000f4 0x020000f4 0x00013 0x00013 
> R   0x1
>       [Requesting program interpreter: /lib/ld-linux.so.2]
>   LOAD           0x000000 0x02000000 0x02000000 0x015d3 
> 0x015d3 R E 0x8000
>   LOAD           0x0015d4 0x020095d4 0x020095d4 0x00138 
> 0x0013c RW  0x8000
>   DYNAMIC        0x00167c 0x0200967c 0x0200967c 0x00090 
> 0x00090 RW  0x4
>   NOTE           0x000110 0x02000110 0x02000110 0x00020 
> 0x00020 R   0x10
> 
> So the '/lib/ld-linux.so.2' is listed here and my 'link spec' for
> gcc-2.95.3 tells too :
> 
> *link:
> %{h*} %{version:-v} %{b} %{Wl,*:%*}    %{static:-Bstatic}
> %{shared:-shared} %{symbolic:-Bsymbolic}
> %{rdynamic:-export-dynamic} 
> %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}   <----- !!
>  -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26}
> %{!mapcs-26:-m armelf_linux} -p
> 
>  Why your GCC now uses a wrong name in its 'specs' is weird,
> none of my 2.9 branch old sources didn't use this name.  Maybe
> you should check your GCC sources and the
>   gcc/config/arm/linux-elf.h
> there for the '-dynamic-linker' name...
> 
> > Now when I execute my program, it says segmentation fault.
> > Does that mean, my tool chain is not built properly? If not what
> > could be the reason?
> 
>  What is the:
> 
>  1. Glibc used in the cross-toolchain ?
> 
>  2. Glibc used in the target system ?
> 
>  Of course these should be just the same or the glibc on the target
> system being newer, so trusting in 'backwards compatability', that
> older binaries will run on newer systems, like binaries for Win98
> running on Win2k or on WinXP, or binaries for RedHat Linux 6.2
> running on RedHat Linux 7.3 ...
> 
>  In your case using a different glibc in the crosstools than on the
> target system shouldn't have any reason, unless you have several
> different target systems with different glibcs on them....  When one
> builds crosstools for a target system, the aim usually is to produce
> stuff for the target system (or for its newer versions), so for RedHat
> 6.2 one uses RedHat 6.2 libraries, but the produced executables
> should also run on RedHat 7.x, 8.x and 9.x... So the 'least common
> nominator' (the oldest) among the target systems is the usual
> choice for the chosen 'target'. 
> 
>  If the glibc used in the crosstools is newer than the one used in the
> target system, that could cause the produced executables crashing...
> 
> > Yes, it picks up the Native as. I have tried giving the 
> --with-as=$TARGET-as
> > gcc configure option. The problem persists. 
> > How do I make $TARGET-gcc to pick the $TARGET-as?
> 
>  Generally the directories seen for 'programs' in the:
> 
>       $TARGET-gcc -print-search-dirs
> 
> output will be searched for 'as' and 'ld', unless there is a 
> bug in the
> GCC sources -- the 'relative search paths' (the '../../../..' 
> ones) don't
> work before the '$prefix/lib/gcc-lib/$target/$gcc-version' in 
> the search
> paths exists. "Richard the Lionheart couldn't go via New Yourk to
> Palestine, only via York".  This bug was present in gcc-2.95.2 and
> precreating the required 'install' directory was the workaround. 
> When building GCC, the install dirs didn't yet exist and so 'as' and
> 'ld' were not found although they were where they should be..
>  
>  I have attached that 'tst_arm-linux-gx' (produced using '-g')
> executable for which that 'objdump -l' was used... It is a
> 'test tprintf' test for glibc, giving quite a lot output, if 
> it works...
> My MinGW-hosted glibc for arm-linux-gnu is from Dec. 2000,
> maybe '2.2.5', but maybe older... If you could check if it runs
> on your Linux/ARM system, that could be nice...
> 
> Cheers, Kai
> 
> 

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com